public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Andrew Schulman <schulman.andrew@epa.gov>
To: cygwin-apps@cygwin.com
Subject: Re: [PATCH cygport] Add a command to make a test release
Date: Thu, 05 Oct 2017 14:23:00 -0000	[thread overview]
Message-ID: <4nectcp0vd3dvhn5rh5ed0h3difc47jedm@4ax.com> (raw)
In-Reply-To: <b70a2040-102e-05f2-ac57-f2a454905f4d@dronecode.org.uk>

> 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

  reply	other threads:[~2017-10-05 14:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 19:51 Jon Turney
2017-10-03 20:01 ` Andrew Schulman
2017-10-03 20:25   ` Achim Gratz
2017-10-05 12:24   ` Jon Turney
2017-10-05 14:23     ` Andrew Schulman [this message]
2017-10-05 16:57       ` Ken Brown
2017-10-05 19:50         ` Andrew Schulman
2017-10-07  7:52           ` Achim Gratz
2017-10-09 19:33             ` Andrew Schulman
2017-10-05 18:16       ` Achim Gratz
2017-10-05 19:33         ` cyg Simple
2017-10-05 18:14     ` Achim Gratz
2017-11-01 19:58 ` Yaakov Selkowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4nectcp0vd3dvhn5rh5ed0h3difc47jedm@4ax.com \
    --to=schulman.andrew@epa.gov \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).