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:16:08PM +0000, Earnie Boyd wrote:
>Quoting Christopher Faylor <cgf-use-the-mailinglist-please@cygwin.com>:
>>On Mon, Oct 12, 2009 at 02:53:36PM -0400, Charles Wilson wrote:
>>>Corinna wrote:
>>>>Here are the questions.  - Does anything speak against the idea of the
>>>>patch?  - Does anybody see a problem with the patch?  - Anything else?
>>>
>>>I think it's great.  I have found it SO useful to have both a
>>>cygwin-1.5 and a cygwin-1.7 tree installed (e.g.  when I break my 1.7
>>>tree I can fix it using familiar cygwin tools from the 1.5
>>>installation, rather than cmd.exe or explorer) -- and I've been able to
>>>do that because the 1.5/1.7 versions *mostly* don't interfere.
>>
>>But, two things to remember: 1) You're an experienced user and 2) We're
>>talking about two different releases.
>>
>>Corinna is talking about allowing any 3PP-cygwin-containing package to
>>calmly coexist with with an official cygwin release.  That means that
>>it is possible for a naive user to be very confused about which version
>>of cygwin they're running.
>>
>>I have more to say about the subject but I don't have the time to say
>>it right now.
>
>Chris, MSYS has been doing this since its first release.  There has
>been zero confusion with end user community and there are many packages
>that have released with their own distribution of MSYS.  If you really
>need to know which version of Cygwin you're running you can always
>include it in the header of the term window.  I use the following PS1
>string in my .profile file.

I don't think MSYS is a strong example.  I doubt that MSYS has a tenth
of the popularity of Cygwin.  It certainly isn't as actively developed.

We often see people confused about which version of Cygwin in the
mailing list even when there is no "cygwin version mismatch" error.
Since the proposed change removes the error, I think that we'll now
likely see more confusion like "I installed the latest version to fix
problem X but it is still there!" And, we'll likely have issues where
the cygwin from directory A creates a file with permissions slightly
different from the cygwin in directory B.  Or the pipes used by one
version of cygwin differ slightly from the pipes used by another.

But, anway, the meta issue that really troubles me is that, AFAIK,
Corinna has always agreed with the
one-Cygwin-per-system-unless-you-know-what-you're-doing rule.  It was
complete news to me that she thought this was a good idea when I first
heard about it.  If I had known she thought it was a good idea I would
have certainly thought twice about the policy.

The ability to run multiple versions of Cygwin has been in the DLL for a
while.  I put it there.  Corinna added a lot in her patch to make it
more solid but her change is no technological breakthrough (I'm not
saying that she is claiming that it is).  We could have always have been
doing this.  As far as I know, the only reason that we weren't doing
this is because we had a policy against it.

The proposed change is coming about because someone wanted to pay for
it.  So, it seems like, for the second time, we're talking about
allowing a Red Hat customer to set policy for the Cygwin open source
project.  I think that maybe everyone but me takes it as a given that
this should be allowed but I think it is a slippery slope.  It certainly
does make it hard for me to be a co-project lead if I can't come to a
decision and know that it will stick.

cgf


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