This is the mail archive of the
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 12 Oct 2009 20:47:52 -0400
- Subject: Re: Avoid collisions between parallel installations of Cygwin
> On Mon, Oct 12, 2009 at 05:17:49PM -0400, Charles Wilson 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
> So we could allow a little
> text file right next to cygwin1.dll with a syntax like:
> 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.
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
> 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 -- but then, I'm just one guy. So far, only
four people have commented on this thread, so I think it's early for cgf
to say "everybody but me" likes the new feature...we really should wait
a few days for others to chime in.
And, making anything new optional is -- usually -- a good thing. Given
the discussion above, I think that'd be ok too.
P.S. I recognized this as a policy change right off, knowing the history
of this MSYS-like functionality that had been consistently rejected in
the past. Since Corinna proposed it, I figured you PTBs had discussed it
offline and decided to change policy. Looks like I was wrong...