Re: [RFC] cygport pm for managing package releases

[Ken Brown <kbrown@cornell.edu>]

On 9/11/2020 12:07 PM, Andrew Schulman via Cygwin-apps wrote:
> cygport has automated a lot of the work of building and maintaining
> packages for Cygwin. But one area where it doesn't help yet is in managing
> the available releases of a package. For me as the maintainer of a dozen or
> so packages, there are routine tasks that I still find to be painful:
> 
> * Finding out which versions of a package are currently available in the
> Cygwin repositories, and which if any are marked as "test".
> * Marking or unmarking a version as "test".
> * Removing versions from the repositories.
> * Marking a package as obsolete.
> 
> All of these are still manual tasks. Most require digging through
> documentation (though that's also much improved in the last few years),
> manually editing .hint files or creating dummy package files, and manually
> uploading files to the right places in sftp://cygwin.com. It's not fun, and
> so I don't keep up with it as well as I should.
> 
> To alleviate that, I think cygport should add a set of "pm" commands to
> automate package management. For example:
> 
> * cygport pm list - list versions available in the Cygwin repositories.
> * cygport pm test - set/clear "test" status for a version.
> * cygport pm del - remove a package version from the repositories.
> * cygport pm obsolete - mark a package as obsolete.
> 
> And probably others. I think this would make maintainer's lives easier, and
> make these management tasks more reliable.
> 
> I can spend some time planning and developing this, and if others want to
> collaborate on it, so much the better. But before I start on that, I want
> to get people's comments here about whether:
> 
> * It's worth doing;
> * (More to the point) It'd be likely to be accepted upstream, assuming the
> implementation is satisfactory; and
> * There may be problems in implementing it that I haven't thought of.
> 
> I can think of a few problems or objections:
> 
> 1. The "pm" commands will bake into cygport logic that's specific to how
> the package repositories and upset currently work. So if those change,
> cygport will have to change to match them. That's true, but not just for
> cygport pm - other parts of cygport, such as cygport up, are basically
> clients for upset. And at least it'll centralize the changes in one place,
> so maintainers won't have to worry about them.
> 
> 2. "pm list" will require finding and parsing an appropriate setup.ini
> file, unlike the other "pm" commands which will manipulate
> sftp://cygwin.com.
> 
> I think these are surmountable, but I want to know if there's a general
> agreement that it's worth doing.
> 
> BTW a successful example like this one is the "cygport up" command, which
> we added a few years ago to automate uploading packages to cygwin.com. I
> think it's working well.

Agreed.  Thanks for doing this.

Concerning your specific suggestions:

 > * cygport pm list - list versions available in the Cygwin repositories.

Good idea.  I often find myself looking at setup.ini to get this information, 
and it would be nice to have cygport automate the process.

 > * cygport pm test - set/clear "test" status for a version.

I like the idea of clearing test status, i.e., 'cygport pm untest'; this should 
be trivial to implement in view of Jon's recent work:

   https://cygwin.com/pipermail/cygwin-apps/2020-August/040440.html

But I'm not sure about going in the other direction.  Once users have already 
installed a non-test package, it could be very confusing to have that package 
retroactively declared to be a test release.

 > * cygport pm del - remove a package version from the repositories.

This would be very useful.  The current mechanism for removing a package version 
is very tedious.

 > * cygport pm obsolete - mark a package as obsolete.

I was about to question the need for this, but I'll bet you're thinking about 
unison2.48.  It will soon become obsolete, with two or more possible replacement 
packages.  So the usual mechanism of having a new package obsolete an old one 
doesn't quite work.

Ken