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 Mon, Oct 12, 2009 at 08:47:52PM -0400, Charles Wilson wrote:
>cgf wrote:
>> On Mon, Oct 12, 2009 at 05:17:49PM -0400, Charles Wilson wrote:
>>>cgf wrote:
>> I think you're assuming that the problems associated with a 3PP would go
>> away.  I'm not so sure, which is probably no surprise.
>
>Well, maybe you're right.  I'm sure it's going to be a tradeoff: some
>issues will go away or get better, but new issues may appear or other,
>existing ones, get worse.  What's the overall impact?  I dunno;
>obviously I lean toward optimism (on this).
>
>But in your other email you raise a good point: given that the impact of
>this change (in policy) is unknown, /that/ should be discussed before it
>"goes in" as a policy change.  Or...make it switchable as you describe.
>But there's a problem with that, too...
>
>> 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.

No, the 3PP would just turn it on in their cygwin.  It would then
be invisible to any other cygwin.  Cygwin doesn't go out of it's way
to scour the shared memory namespace looking for potential conflicts.

>> So we could allow a little
>> text file right next to cygwin1.dll with a syntax like:
>> 
>> .cygwinrc
>> allow-multiple: yes
>> ntsec: yes
>> tty: yes
>> crlf: yes
>> 
>> 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.

Or, if you want, you'd set this for your Cygwin too.  There's no reason
not to.

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

Yes, and I presume that "someone else's problem" would satisfy the
nameless Red Hat customer who presumably wants to release their own
version of Cygwin without worrying about other versions.

>> I'd feel better about something like this because we would be actually
>> extending cygwin functionality rather than arbitrarily changing policy
>> because some unknown entity wants to pay for it.
>
>I *think* adding this feature, and enabling it by default (as Corinna's
>patch does) is a net gain

Not sure what you mean by this feature.  If you mean allowing multiple
cygwins by default then I can't see any reason to ever disable it if you
enable it by default.  It won't help in tracking down a problem since
you won't know which version of cygwin to turn off.


cgf


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