Re: [RFC] cygport pm for managing package releases

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2020-09-12 09:03, Ken Brown via Cygwin-apps wrote:
> 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.

Python 2/2.7 (308) packages also come to mind as being dropped at some point in
the next year as there is no longer any support.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]