[RFC] cygport pm for managing package releases

[Hamish McIntyre-Bhatty]

On 12/09/2020 22:20, Brian Inglis wrote:
> 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.
>
I would definitely find these features helpful so you have my vote on
these additions for sure.

Hamish

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x87B761FE07F548D6.asc
Type: application/pgp-keys
Size: 3183 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin-apps/attachments/20200912/f1eba75a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin-apps/attachments/20200912/f1eba75a/attachment-0001.sig>