This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


On Tue, Oct 13, 2009 at 09:54:37AM +0200, Corinna Vinschen wrote:
>On Oct 12 20:47, Charles Wilson wrote:
>> cgf wrote:
>> > I'd feel better about the change if it wasn't the default but could be
>> > turned on by a knowledgeable user. 
>> 
>> 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.

I think everyone here understands the policy change.

>> > and that could be used *by knowledgeable users* to control their cygwin
>> > behavior.  Or, we could even create a tool to place that information
>> > into a "capabilities" section in the DLL itself.
>> 
>> 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.
>> 
>> We'd still get interference, if the 3PP *doesn't* do this.  And if they
>> DO do it, then we have UNknowledgable end users with a copy of cygwin on
>> their system that has this "feature" enabled...and they didn't do it,
>> and don't know about it.
>> 
>> Is this a good thing?
>> 
>> Probably. Any problems would be because the end user used the 3PP tools
>> to <do something> and then tried to <do something else> with the "real"
>> cygwin, or vice versa.  That's a 3PP integration issue -- e.g. Somebody
>> Else's Problem.
>
>If you make this feature optional, *and* default to off, the entire
>potential advantage is moot.

The entire advantage is not off.  You can distribute your own version of
the DLL and not have it interfere.  I would have thought that this would
satisfy any customer who was thinking about bundling the DLL with their
product which, we can only assume, is why this was implemented.

>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.

You're again assuming that it is a bad thing to detect multiple versions
of Cygwin.  So, again, I'll point out that we've been able to isolate
the cygwin shared namespace for years.  "We" simply have chosen not to
do it.  This is not a bug fix or enhancement.  It's a policy change.

Since you already modified the 1.7 DLL to coexist with 1.5 I don't see
why we'd turn that off.

And, I still submit that we'd like to *know* when someone distributes
the DLL.  The policy of "always use the newest" still makes sense to me.

>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.

I don't really care if a 3PP wants to use Cygwin without understanding
it.  If something like this idea was implemented we'd have a nice FAQ
entry for a 3PP which advises against installing their own DLL but tells
them how to prepare it if they really felt they had no choice but to
bundle it.

Btw, you probably shouldn't be referring to people as 3PPs if you are
intent on allowing them to do this.  It's a rather derogatory term to
use for someone who isn't, in your eyes, doing anything wrong.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]