per-version hints proposal

Corinna Vinschen
Fri Dec 9 10:46:00 GMT 2016

On Dec  8 19:30, Jon Turney wrote:
> On 30/08/2016 13:24, Jon Turney wrote:
> > This file is called override.hint.
> While not a great deal of use is made of test versions, this mechanism
> doesn't seem to be working well for that, and there have been several
> requests to improve it.
> There's no automation to generate override.hint, and writing it correctly
> requires too much knowledge about how calm is going to process it.
> [...]

ACK.  It's kind of backwards compared to the new layout with per-version
hint files.

> The proposal to address this is:
> Add support to calm for a 'test:' line in PVR.hint, marking a version as a
> test version.


> If multiple versions are marked test, the highest version will be used as
> the test version in the generated setup.ini (and thus offered for
> installation using the 'exp' control in setup.)
> (Note to self: why isn't this control labelled 'test', which is an actual
> english word???)

Note to jturney, change it, don't be shy.

> Versions marked as test cannot be used as curr: (so test versions are never
> automatically promoted to curr)
> override.hint will continue to work, and, if one exists it takes precedence
> over these rules.

I would rather drop it as an evolutionary dead end.

> cygport will be updated to (details TBC) accept a --test flag which is
> significant to the cygport package stage, and adds this 'test:' line to all
> the generated PVR.hint files.

--test would be fine.

> To promote a package from test to curr, a script will be run on sourceware
> to remove the test: line from the existing PVR.hints in a given package
> subtree, for a given VR.
> Since this requires shell access on sourceware, if you don't have that, you
> can ask here or on #cygwin-developers.

I don't think this is feasible.  The maintainer should have control
over the promotion from test to curr.  I'm not affected by this since
I generate new versions as soon as I promote, so this is more maintainers
like JonY, for whom a rebuild and reupload of the gcc packages just to
promote test to curr is quite a burden.

First, not well thought out proposal:

- cygport gets a new command, e. g.

    cygport foo.cygport {promote|untest|currify}

  This command has only one purpose.  It uploads a file !untest
  to the maintainers upload area, with a single line containing
  the version number from the foo.cygport file, i. e.

  - Fetch $PVR from foo.cygport, e. g.  2.24-1.
  - echo "$PVR" > !untest
  - lftp !untest to

- While creating the ini file, calm looks for !untest files.  If one
  is available, check the version number.  If there's a matching PVR.hints
  file, drop the test marker.  Continue with creating the ini file.

> I would like to provide an automatic mechanism to allow package maintainers
> to promote their own test packages, but there are a few stumbling blocks in
> the way of that, currently.



Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin-apps mailing list