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.]
