Re: per-version hints proposal

[Jon Turney <jon.turney@dronecode.org.uk>]

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 
or not.

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.