From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84496 invoked by alias); 5 Oct 2017 14:23:59 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 84372 invoked by uid 89); 5 Oct 2017 14:23:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=4801, 4.8.0-1, 4771, 4.7.7-1 X-HELO: blaine.gmane.org Received: from Unknown (HELO blaine.gmane.org) (195.159.176.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Oct 2017 14:23:56 +0000 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1e073w-0005LK-OW for cygwin-apps@cygwin.com; Thu, 05 Oct 2017 16:23:44 +0200 To: cygwin-apps@cygwin.com From: Andrew Schulman Subject: Re: [PATCH cygport] Add a command to make a test release Date: Thu, 05 Oct 2017 14:23:00 -0000 Message-ID: <4nectcp0vd3dvhn5rh5ed0h3difc47jedm@4ax.com> References: <0756319a-94e5-d3d3-507a-2aee9418aca6@dronecode.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive: encrypt X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00034.txt.bz2 > On 03/10/2017 21:01, Andrew Schulman wrote: > >> This patch (originally by Achim Gratz) adds a mechanism for generating > >> packages marked as 'test' as described in [1]. > >> > >> I'm not committed to any of the details, but I would like to get > >> something with this functionality in, so tell me how you'd like it > >> implemented and I'll do it... > >> > >> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg00005.html > > > > Cygport needs a way to specify which versions are prev, curr, and test in > > cygport files. David Rothenberger and I each proposed a method [1,2]. It > > doesn't matter much to me which method is picked, but it's definitely a > > missing feature. > > I'm not keen on the idea of including this transient information into > the cygport, and thus baking it into the source package. > > However, I also want to make package maintainers lives easier. So, I'm > all for automation to make things less tedious and error-prone, which > this patch attempts to do. > > A few points to consider: > > * I'm going to remove the restriction that you can only have 3 versions. > (I keep on putting this off only because it will break parsing setup.ini > for setup prior to 2.877) > > * (This also means that more than one test: version may be available) > > * Changing curr: doesn't cause setup to downgrade (since 2.864) (unless > --force-current is used, since 2.874) > > * prev: isn't a very significant label, since the only way to install > that version is by manually selecting it, i.e. all it means is "keep > this version around" > > Taking a step back, as a package maintainer, what do you need to > control? What features do we need here? Thanks. Most commonly, I just want to make a version test, which this patch allows. Sometimes more complicated situations come up. We have one with lftp right now: prev: 4.7.7-1 curr: 4.8.0-1 test: 4.7.8-1 This happened because 4.8.0-1 turns out to be broken, and later versions won't build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay, shortly I want to promote it to current and dump 4.8.0-1, leaving prev: 4.7.7-1 curr: 4.7.8-1 I can do this by creating an override.hint file, but right now I have to upload that manually. It'd be nice if I could tell cygport to handle it, in whatever way is best. I think it's fine to put the prev, curr, and test instructions in the cygport file, and have it create and upload the override.hint. cygport files already have version information in them (VERSION, RELEASE). But if you don't like that, we could ask maintainers to create override.hint files separately, and just have cygport recognize and upload those. That's fine too, as long as there's a way to allow different override.hint files by arch, which is bound to be needed sometimes. Andrew