This is the mail archive of the
mailing list for the Cygwin project.
setup.exe considerations (was: Doubtful about unison)
- From: Matthias Andree <matthias dot andree at gmx dot de>
- To: cygwin at cygwin dot com
- Date: Tue, 01 Mar 2011 11:57:07 +0100
- Subject: setup.exe considerations (was: Doubtful about unison)
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <4D6BFD09.email@example.com> <AANLkTimi6R8MFSH63quHW3EqV4z5ucwtgNEPmCWWfjjc@mail.gmail.com>
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.
In this particular example, it would mark "alternatives" and "cygwin"
for update as direct unison2.32 dependencies, and recursively also
libintl8, libiconv2, base-cygwin, and libgcc1.
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.---I've been doing that for over four
years and the only thing that hicc-upped regularly (and required
rebasing or peflagsall) was git-svn.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple