Avoid collisions between parallel installations of Cygwin
Tue Oct 13 14:20:00 GMT 2009
> On Oct 12 20:47, Charles Wilson wrote:
>> But if it is NOT the default, then 3PP installations would still
>> interfere with "the real" cygwin, unless the user "turns on" this
>> feature manually.
> That's exactly the problem. The policy change is done by implementing
> this feature at all. You gain the advantage by the fact that it's
> possible to run multiple Cygwin's in parallel.
>> Oh, wait: I see. So "the real" cygwin would default to the current
>> behavior, but it would be up to 3PPs to ensure that THEIR cygwin
>> installation DOES turn on the new feature.
> 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.
Current situation: if you have a net distribution and a 3PP, then
(depending on PATH settings and use case), BOTH installations will
"fail" -- that is, the cygwin duplicate detection code will fire off the
I'd think this would be of concern to the 3PP, as well as us -- that the
presence on their users' hard drive of the official net release cygwin
could "break" their product. (Not to mention that their users would be
upset that their "normal" cygwin installation would be "broken" by
installating the 3PP's product). And -- since at least one 3PP is
willing to pay for a fix -- it seems I'm correct.
With the new behavior, made optional but defaulting off, as cgf
proposes, we have four new cases:
1) neither the cygwin net release nor the 3PP "activate" the feature
2) the cygwin net release does not active the feature, but the 3PP does.
3) the end-user activates the feature for his net release installation,
but the 3PP does not.
4) the end-user activates the feature for his net release installation,
and the 3PP's distribution also activates the feature.
Case #1 is the status quo. The arguable benefit of this situation, and
the rationale that has been used for years to justify the error
detection code in cygwin, is that this allows us to tell end users:
"You have a 3PP-installed cygwin, and they are supplying an
old -- presumably more-buggy-than-current -- cygwin DLL. Either
replace it with a newer copy (which will fix the problem *now*
but it will recur next time you update your cygwin installation),
or preferably remove it and set PATH so that the 3PP product
uses the actual net-release /bin/cygwin1.dll. Alternatively, you
can create a new file in <3PP>/bin/.cygwinrc [*] and add 'allow
multiple: yes' to silence this warning permanently -- but be
warned that you may then suffer from poor behavior in the 3PP
tools as we continuously fix bugs in the net release."
This way we "help" end users and 3PPs to always have the most recent
cygwin DLL, benefiting from all known bugfixes.
[*] or "run this tool on <3PP>/bin/cygwin1.dll and set 'allow multiple:
The downsides are (a) this plays hell with configuration management. A
3PP wants to KNOW, beyond question, EXACTLY what software is being used
by their product, right down to the known bugs and behaviors of the
cygwin DLL. Otherwise, their customer support department is at the mercy
of whatever policy decision we, the cygwin developers, make at any point
in the future. (b) it's really bad form, from the 3PP users' standpoint,
that the 3PP product "breaks" because -- as far as the end user knows --
she installed some completely unrelated product over in C:\cygwin.
So, if the 3PP wants to prevent (a) and (b), and does NOT want their
users to receive the warning in #1 and "break" (or, "and benefit from
newer cygwin DLLs except only as the 3PP's QA team decides to ship new
updates for their installation on their schedule not ours"), then the
3PP would now have a way to implement THEIR policy in THEIR
distribution. This is case #2.
So, case #2: In this case, the 3PP is "protected" from errors/conflicts
with the cygwin net release, and vice versa. However, the end user is
also prevented from receiving the warning noted above -- and when he
uses the 3PP tools may suffer from known, fixed cygwin bugs. But that's
the 3PP's problem, not ours. If the end user complains, we NOW say:
"That bug is fixed in current cygwin. Check <3PP>/bin/.cygwinrc
for 'allow multiple: yes'. [*] If so, then complain to the 3PP
that they should update their product to use the latest cygwin
release. If not, <repeat advice from #1, above>"
[*] Or "run this tool on <3PP>/bin/cygwin1.dll, and check the output for
'allow multiple: yes'..."
Case #3: This would probably happen when the user ran in to case #1, and
elected to "protect" their cygwin net release from all such 3PPs.
That's the end user's choice -- but they should make it knowing that it
robs them of the (arguable) "benefit" that we have long used to justify
the error in the first place: they will no longer be warned that one or
more of their separate cygwin installations is using an out-of-date
cygwin DLL. But that's the end user's choice to make, not ours.
Case #4: this is (in effect) what would happen if we made the new
behavior the default. But, let's assume for this paragraph that both
the 3PP opted to turn on the option manually, and the end user also
manually did so for the net release. In that case, the benefits and
drawbacks of both cases #2 and #3 apply -- but in each case, the
decision to accept those drawbacks and gain those benefits was made by
the 3PP and the end user; not us.
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.
> 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
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
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
Now that I think about it, this is ALSO a danger exposed by the mere
existence of the proposed option: even if the net release doesn't turn
it on, if a 3PP does, then the above scenario could occur.
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?
</end Tolstoy mode>
More information about the Cygwin-developers