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 Oct 13 09:19, Christopher Faylor wrote:
> On Tue, Oct 13, 2009 at 09:54:37AM +0200, Corinna Vinschen wrote:
> >If you make this feature optional, *and* default to off, the entire
> >potential advantage is moot.
> 
> The entire advantage is not off.  You can distribute your own version of
> the DLL and not have it interfere.  I would have thought that this would
> satisfy any customer who was thinking about bundling the DLL with their
> product which, we can only assume, is why this was implemented.

That was obviously the intention of the customer in the first place.  In
the meantime I am quite happy with this change in a generic way since at
one point I started to see the advantage in this.

> >The one Cygwin installation we're interested in, the net distribution,
> >does not use it, so it's the one prominent Cygwin installation which
> >will fail as before if 3PPs forget or just don't know about this
> >feature.  Or don't care.  Or, are simply using a 1.5 based Cygwin and
> >pipe names still clash.
> 
> You're again assuming that it is a bad thing to detect multiple versions
> of Cygwin.  So, again, I'll point out that we've been able to isolate
> the cygwin shared namespace for years.

...except for pipes/ttys (just for the records).

> "We" simply have chosen not to
> do it.  This is not a bug fix or enhancement.  It's a policy change.

Yes, it's a policy change.  And a good one in my eyes.  I think it's a
good thing in general that we don't *have* to detect multiple
installations of Cygwin since they just don't interfere with each other.
The change doesn't mean we don't detect them, it just means we will
detect them only in the now rather seldom instances in which they do
interfere via the exec call.  As long as the applications in the
different installations are not, say, run in the same console window,
they can happily co-exist.

> Since you already modified the 1.7 DLL to coexist with 1.5 I don't see
> why we'd turn that off.

We don't, but we win by not having to care in most cases.

> And, I still submit that we'd like to *know* when someone distributes
> the DLL.  The policy of "always use the newest" still makes sense to me.

I can't see an advantage that the DLLs fight that out on the back of the
user.  Typical 3PP (3rd-Party-Product) installations have a very limited
usage.  For instance, packages containing just SSH and a small set of
necessary tools.  Or a CD burning package.  Or a cross-compiler package.
They are all meant to run on their own, without interference with other
packages.  And as soon as the user tries to use applications from
different installations together, the "multiple cygwin" message will
re-appear anyway.  Given that, I don't see how this is making our lives
harder on the list.  If anything, it will become easier because it the
problem occurs in fewer, more controlled circumstances.

Having said that, "always use the newest" is still a good idea(*).  But
I don't think it makes everybody's life happier to rub this in with a
stick.


Corinna

(*) Except in rare cases in which some applications chokes on a new
    Cygwin API behaviour.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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