This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH cygport] Add a command to make a test release
> 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 .
> >> 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...
> >>  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?
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:
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
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.