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

Quoting Christopher Faylor <>:

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.

The phrase "actively developed" isn't the same as "actively used". I know of at least 3 or 4 distributions of MSYS that put the system underneath their own directories.

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.

That possibility exists of course but how likely is it to happen? Out of the thousands of posts in Cygwin mail list, how many are confused about the versions being mismatched? And with this change how will that figure change? I'm guessing that there will be no more and no less difference in the confusion.

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.

And it was that code that led me to make it policy for MSYS to allow it to happen.

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.

I know that paying customers talk louder than the non paying ones but this *is* a selling point for MSYS vs Cygwin, "actively maintained" or not. And the more Cygwin begins to look like MSYS the happier I am.


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