From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id A3CED3857C62 for ; Sat, 12 Sep 2020 21:20:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A3CED3857C62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id HCwFks3EH62brHCwGkAeJH; Sat, 12 Sep 2020 15:20:04 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=RZ24vCjvlsqmbDxLIRQA:9 a=zDdJ3fYtI2ki41Cz:21 a=6S07_XiNeAjv7wz_:21 a=QEXdDO2ut3YA:10 a=NV5DKWQTh5MA:10 a=sRI3_1zDfAgwuvI8zelB:22 Reply-To: cygwin-apps@cygwin.com Subject: Re: [RFC] cygport pm for managing package releases To: cygwin-apps@cygwin.com References: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> <748949da-68b5-03ae-aa87-9e03a5e70d1c@cornell.edu> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: Date: Sat, 12 Sep 2020 15:20:03 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <748949da-68b5-03ae-aa87-9e03a5e70d1c@cornell.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNmv3o37ho/S26VQn6y9c3K3G25AaePQ8ebs/ZBKJ9fDwQucicLmFTTPtbqGob+y5MHgoYmXRfdhk+JLSO1t17uRbYbrt/vgPS0QO5fGgWpIyytLO5G0 qj8Kh48TYRvWDB0Yar4spi2/Vnwc4u3doVz1Be5qp+irtTUs/qmUjaNVYcFLZC/HkOzqhAetCXUWUg== X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 21:20:07 -0000 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.]