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
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
