This is the mail archive of the
mailing list for the Cygwin project.
Re: per-version hints proposal
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 8 Dec 2016 19:30:19 +0000
- Subject: Re: per-version hints proposal
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
On 30/08/2016 13:24, Jon Turney wrote:
On 20/06/2016 16:28, Jon Turney wrote:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate this problem out of existence, I suggest replacing the
setup.hint file in an upload with a package-version-release.hint file.
* 'curr', 'prev' and 'test' don't make sense on a per-version basis. So
I suggest a separate file for these version overrides (versions.hint?)
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.
(e.g. if the curr: version is N, we can upload a version N+1 as test:
with an override.hint that says 'test: N+1', but if we then want to
upload version N+2 as a replacement test, you need to know that you
should write an override.hint that says 'curr: N test: N+2' otherwise
calm will automatically promote N+1 to curr (and vault any N-1, which
makes this a pain to revert))
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???)
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.
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.
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.
If all the people with shell access are unavailable, if you still have
the cygport build directory, you can manually amend all the PVR.hints
under PVR.arch/dist/ to remove the 'test:' line, and re-upload them.
Finally, the package can be rebuilt with a bumped release number and
without --test, although opinion is mixed as to if this is a good idea
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.