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 05:17:49PM -0400, Charles Wilson wrote:
>cgf wrote:
>>On Mon, Oct 12, 2009 at 02:53:36PM -0400, Charles Wilson wrote:
>>>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.
>
>Sure.  Once 1.5 goes poof, I was thinking of setting up on my machine a
>bare-bones C:\cygwin-1.7-fallback installation for this sort of
>thing...I had planned to use a debug-built cygwin DLL for this, so that
>the shared data items would be isolated.  But exploiting this new
>behavior Corinna is talking about will be better.

I've been keeping a separate, minimal version of cygwin available for
about twelve years now.  If you build the DLL with --enable-debugging
it defaults to allowing multiple versions, although sometimes you do
have to set CYGWIN_MISMATCH_OK too.

But, again: knowledgeable user.  I don't have problems with people who
won't whine to the mailing list having multiple versions.

>>Corinna is talking about allowing any 3PP-cygwin-containing package to
>>calmly coexist with with an official cygwin release.
>
>Right -- that's different than what I intend to use it for.  But the
>behavior will be there, and it'll work for me, for this purpose.  So
>that makes me happy -- and I was going to be sad when 1.5 went poof.
>And allowing 3PP to do whatever they want without affecting us is
>GREAT.  'Cause as much as we would like, they ain't goin' away, and
>they're gonna keep doing.../that/.

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.

I'd feel better about the change if it wasn't the default but could be
turned on by a knowledgeable user.  How about if we did something like
allow multiple versions if you've done a:

chmod u+s cygwin1.dll

Doing that would cause that version of the DLL to create unique shared
memory regions.

Ok, that wouldn't work for a FAT/FAT32 dll.  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.

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.

cgf


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