This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH setup] Allow setup to parse more than 3 versions from the setup.ini file
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 31 Aug 2016 11:48:40 +0100
- Subject: Re: [PATCH setup] Allow setup to parse more than 3 versions from the setup.ini file
- Authentication-results: sourceware.org; auth=none
- References: <1433349024-9776-1-git-send-email-jon.turney@dronecode.org.uk> <20150608134318.GO3416@calimero.vinschen.de> <87d216nguv.fsf@Rainer.invalid>
On 08/06/2015 20:24, Achim Gratz wrote:
Corinna Vinschen writes:
I'm not against adding some functionality along these lines (provided
you also fix upset), but I'm not so sure about the broad definition of
the version state pattern. It feels as generating problems down the
road. Think setup.hint. Your patch would requite to recognize more or
less any string as version state:
Thats easily fixable by requiring a constant prefix ("ver-" or even just
"v" looks like something that should work).
Agreed.
But besides that issue I don't think that setup.exe makes this easily
useable. If I understand the motivation of John correctly, he'd want to
keep an older version of the X server installable, or maybe as another
example let's say I'd want to make it possible to keep perl-5.14 around
for a while. I don't think people would want to click on hundreds of
chooser boxes until they have some set of old versions that are (or
maybe not) working together. This is only useful if that set of old
packages can somehow be ganged together and switched all at once, IMHO.
This probably means a meta-package that pulls in versioned dependencies.
That is indeed another piece of the puzzle, and something I intend on
working on.
The dirty little secret of setup is that it already has those versioned
dependencies and can probably also deal with different dependencies for
each trust level and replace packages (in other words, the obsoletiohn
dance we're normally doing may be unnecessary). It also has recommends,
suggests, depends and conflicts. These features have quite likely
bit-rotted and documentation is almost non-existing, but they're already
built in.
'never finished' rather than 'bit-rotted'