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.9]) by sourceware.org (Postfix) with ESMTPS id B925F385782F for ; Fri, 11 Sep 2020 23:07:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B925F385782F 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 Gs8dkCALZ195BGs8ekzJLy; Fri, 11 Sep 2020 17:07:29 -0600 X-Authority-Analysis: v=2.4 cv=Wfqy12tX c=1 sm=1 tr=0 ts=5f5c0331 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=D-hjUeOzi2gWLipTs3oA:9 a=y2Bb0grD1prRpo9G:21 a=BSdr3k2XMcITq5p0:21 a=QEXdDO2ut3YA: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> 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: <496c460b-637b-47d5-9def-4ba9e21e25f3@SystematicSw.ab.ca> Date: Fri, 11 Sep 2020 17:07:27 -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: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfGW2wepLtjoi0y3EcTaprzzwczP5BDmnixP83RWm07w3Qp7jCZoVMYbliczRSn9I6SiQGE/FKLa5BhbcoyVM61PtgM45+tPxUbyVmAzdTLJFqOxM0mP8 J/DmqhzCf2/aydgQR8rhIT6J2i2H56bP5j2ZiDpV+6SiGjynhFkWwVmNFT4GNLJht4j75As6US8IEVsplAxjea91pHV6mjeeYrs= X-Spam-Status: No, score=-8.1 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: Fri, 11 Sep 2020 23:07:32 -0000 On 2020-09-11 10:07, 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. Also cygport commands package-test and all-test added more recently should make test package management easier. I and others have forked and hack updates to apt-cyg (static) on github, and push changes to our forks when they are stable enough, and find that allows me to easily do a lot with setup.ini and installed.db. Perhaps we should first outline the maintainer packaging workflow, including required functions such as creating a package directory and contents, checking for other repos with a package, sending ITPs/ITAs and SSH public keys, checking licensing, checking for new upstream releases, and less common functions such as those you mention, sending upstream emails and submitting patches or PRs, and others, with a summary like the cygport --help output, description as in the cygport HTML help, specification of what is needed and why, and example commands to execute, if known, to implement the function. Perhaps the additional functions and commands could be guided by the functions provided for Gentoo portage tools, Debian dh, Fedora fedpkg, and OpenSuSE osc packaging tools. Other functions could be like OpenSuSE osc submitrequest, requestmaintainership to send standardized ITPs/ITAs, Debian equivs to create trivial package files, lintian/fedpkg lint to check package metadata, etc. Once we have a list of maintainer functions, we should consider what maintainers consider pain points to add as cygport commands, plus quick and easy wins to help maintainers contribute while understanding cygport development and docs. I like the single word commands in cygport and other tools e.g. your pm list is like apt show, pm test and pm obsolete remind me of apt mark, and possibly also pm del, depending on whether you expect those commands to work on .hint files or upload directories or both, and distinctions and expectations like those need to be explained. Should we work with patches, PRs, a dev repo (on sourceware? or github) against https://cygwin.com/git/?p=cygwin-apps/cygport.git, or other storage space(s), to maintain lists of workflows, suggested functions, maintainer pain points, possible commands, command summaries, outlines, help descriptions, spec details, and commands to execute in an implementation. -- 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.]