[PATCH setup] Allow setup to parse more than 3 versions from the setup.ini file

[Jon Turney]

On 31/08/2016 11:48, Jon Turney wrote:
> On 08/06/2015 14:43, Corinna Vinschen wrote:
>> On Jun  3 17:30, Jon TURNEY wrote:
>>> Reminded by a recent request as to how to install
>>> xorg-server-1.17.1-2, which
>>> has disappeared beyond setup's ken (in order to determine if there was a
>>> regression in the curent version), this is a re-send of a patch I
>>> originally
>>> submitted back in 2011 [1], which received an ambiguous response then.
>>>
>>> [1] https://cygwin.com/ml/cygwin-apps/2011-04/msg00053.html
>>>
>>> This recognizes any "[foo]" line as introducing the information for
>>> another
>>> version, which doesn't have one of the trust levels [curr], [prev] or
>>> [test],
>>> and so isn't automatically selected when setup is told to install all
>>> packages
>>> at that trust level (by default, [curr]).
>>>
>>> Setup already does all the neccessary sorting in version order etc.
>>> to use these
>>> additional versions.
>>>
>>> Since the value of <foo> carries no meaning, it might make sense to
>>> update the
>>> setup.ini specification to mandate the use of specific strings like
>>> "[also]" or
>>> "[other]", or perhaps "[prev-1]", "[prev-2]", etc.
>>>
>>> I have written a corresponding patch to genini.
>>>
>>> I'm not sure what expiry policy is currently used by upset for old
>>> packages, but
>>> presumably that would need to be made more sophisticated, along with
>>> the changes
>>> needed to generate setup.ini entries for other versions.
>>
>> Upset does not handle expiry of packages at all.  Versions are mentioned
>> in setup.hint as test, curr, prev, or exp (yes, really) and those are
>> handled, everything else throws an error message.  Package versions not
>> mentioned in setup.hint are simply ignored.
>
> Yes, upset doesn't (didn't) explicitly handle expiry, but the fact that
> a package version is not mentioned in setup.ini causes it to be removed
> by stalepkgs, when that is next run.
>
> After the corresponding change to setup.ini generation, it will list all
> versions, so none would ever be eligible for expiry under that policy.
>
> Anyhow, improving that is close to the top of my hit-list for calm.

calm now handles package expiry as of [1], so, pinging this.

There also exists a corresponding calm patch [2], to generate setup.ini 
listing more than 3 versions (This should not be deployed until some 
time after a setup with the above patch has been released)

[1] https://cygwin.com/ml/cygwin-apps/2016-09/msg00021.html
[2] 
https://github.com/jon-turney/calm/commit/cf5497063b146cc7442437b5047e318d9a074769