Avoid collisions between parallel installations of Cygwin
Tue Oct 13 15:34:00 GMT 2009
On Oct 13 10:19, Charles Wilson wrote:
> Corinna wrote:
> > If you make this feature optional, *and* default to off, the entire
> > potential advantage is moot. The one Cygwin installation we're
> > interested in, the net distribution, does not use it, so it's the one
> > prominent Cygwin installation which will fail as before if 3PPs
> > forget or just don't know about this feature. Or don't care. Or,
> > are simply using a 1.5 based Cygwin and pipe names still clash.
> No, I don't think that's the correct analysis.
> But if we make the new behavior the default, then WE would have decided
> that the "benefit" of the warning message is no longer important, and WE
> would have decided that 3PP installations will never be flagged as using
> an old cygwin with old bugs. Its kinda says that the argument we have
> used for years to justify the warning message in the first place no
> longer applies, or is no longer an important consideration.
Actually, most 3PP (still: Third-Party-Product) installations don't
actually care for the latest version of the DLL. The features used by
this installation are available in this very DLL. There's no reason to
update as long as it works for the intended purpose. Whatever we think
about 3PPs, and whether or not we care for 3PPs, the people creating
3PPs would be very likely very happy to have no collisions, and they
won't be angry with us to take this burden from them.
This is still possible with making this optional, but I'm quite sure
that not only the 3PP guys, but also most users of the Cygwin net distro
and 3PPs based on Cygwin will be quite happy to have less collision
problems, too. As far as 3PPs go, most users don't even know or care
that there's some weird CigWIn DLL required to run the stuff.
> > If this feature should make any sense, it's important that the net
> > distro DLL uses it by default. If the feature is made optional and
> > 3PPs don't use it, it's their DLLs which will fail when used together,
> > but not ours.
> Yes -- but since many 3PPs extend the system PATH to include their
> installation directories, I could see cases where users' apps installed
> into <netrelease>/usr/local/bin might break in odd ways (in the old
> days, this would have most affected X apps in /usr/X11R6/bin but that's
> not as much of a problem now that X apps are installed into /bin). We
> wouldn't see problems from a bash shell, because /etc/profile sets PATH
> to put /bin near the front, but shortcuts to /opt/*/bin/* or
> /usr/local/bin/* might mistakenly get the 3PP's cygwin1.dll. Currently,
> the end user will get the big ugly warning about multiple DLLs. With
No. That's not at all guaranteed. The process gets the first DLL in
the DLL search order. As long as there's no second process running by
chance using the other DLL, you won't detect any problem. Which, btw.,
is none, as far as the user is concerned. The problem is that we make
a problem of it.
> making the new behavior the default, she will simply be subject to
> whatever bugs exist in the old cygwin1.dll shipped by the 3PP -- or
> subject to "enhancements" the 3PP has made to their version. And she'll
In which case it's not such a great idea to point the user to the latest
Cygwin net distro version. If a 3PP really has made extensions to the
Cygwin DLL required for their product, the "update" will probably not
have the desired result.
> complain to the list about the behavior, and we will have a very hard
> time tracking down the problem because it won't show up when she runs
> the shortcut target command from a bash shell...until we get the
> cygcheck output, and postulate that 'hey, maybe when you launch
> /usr/local/bin/bob you're accidentally getting this other cygwin1.dll
> over there...'.
That's not a new problem. If the /usr/local/bin/bob tool is started
from a shortcut and catches the other DLL, this will work like a charm
if no other Cygwin process using the "good" DLL is running. With the
current state the user might get a blinking Window which simply
disappears again. That's not much better than getting a working
applications which might or might not hit a bug in the other DLL.
> What it boils down to, is: Do we now consider the big ugly duplicate
> cygwin warning to be a *problem*, rather than a *benefit*? I'm not sure.
> cgf apparently continues to maintain that it is a benefir. Obviously the
> unnamed customer considers it a problem. But this is *our* decision, not
> theirs. What do you think, Corinna? Anyone else?
The mutiple Cygwin version warning is a benefit in the cases in which
a collision occurs. If we can make sure that collisions only occur in
rare cases or (far future) never, then that's great. IMHO. YMMV.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-developers