This is the mail archive of the
mailing list for the Cygwin project.
Re: setup.exe considerations (was: Doubtful about unison)
- From: Andy Koppe <andy dot koppe at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 1 Mar 2011 12:46:05 +0000
- Subject: Re: setup.exe considerations (was: Doubtful about unison)
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <4D6BFD09.firstname.lastname@example.org> <AANLkTimi6R8MFSH63quHW3EqV4z5ucwtgNEPmCWWfjjc@mail.gmail.com> <4D6CD103.email@example.com>
On 1 March 2011 10:57, Matthias Andree wrote:
> Am 01.03.2011 08:20, schrieb Andy Koppe:
>> On 28 February 2011 19:52, Matthias Andree wrote:
>>> Which is the problem: the unison command was compiled against a newer
>>> cygwin1.dll than yours.
>> To be fair, setup.exe ought to be able to resolve or warn about such
>> version dependencies. Unfortunately the infrastructure for that isn't
>> in place, as it would require version requirements to be expressed in
>> packages' setup.hint files (rather than in their READMEs, as they are
>> at the moment).
> No it doesn't require such version dependencies.
> As a lightweight alternative, setup.exe might just recursively select
> all "requires" packages that a newly installed or upgraded package
> depends on "for update" (possibly from the same version branch,
> curr/test/prev), making sure not to implicitly downgrade.
Good idea, although that would entail unnecessary (and unwanted)
updates, for example, the Cygwin DLL would get updated whatever
package you installed, even if the package was built years ago.
> On the other hand, Cygwin package maintainers do a pretty good job of
> not breaking existing setups, so "update everything" (to the "curr"
> version) is usually a safe bet.
True, and anything else is unsupported.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple