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 14:37, Christopher Faylor wrote:
> On Tue, Oct 13, 2009 at 06:23:36PM +0200, Corinna Vinschen wrote:
> >On Oct 13 18:08, Corinna Vinschen wrote:
> >> On Oct 13 12:00, Christopher Faylor wrote:
> >> > On Tue, Oct 13, 2009 at 05:37:48PM +0200, Corinna Vinschen wrote:
> >> > >On Oct 13 15:50, Thomas Wolff wrote:
> >> > >>About the "allow parallel installation" configuration: if needed at all
> >> > >>(as I understand it, the "always allow it" option is still open in the
> >> > >>discussion), why not have it simple and dynamic with the CYGWIN
> >> > >>environment variable?
> >> > >
> >> > >The environment is read much later than the first shared objects are
> >> > >created.  Sure, we could just move reading $CYGWIN to a much earlier
> >> > >point without breaking anything.  At least this would keep the
> >> > >configuration in the same single spot.  But I'm still not convinced
> >> > >that making this behaviour optional has any advantage.
> >> > 
> >> > Of course it has *some* advantage.  It allows us to sometimes more
> >> > easily figure out when someone who is reporting problems has a problem
> >> > because they have an older version of cygwin.
> >> 
> >> What's that "sometimes" exactly?  Right now, we have usually two
> >> scenarios.  One is fixed by calling cygcheck and pointing the user to
> >> "please update your version of Cygwin to the latest".  The other is we
> >> figure out that the user is not talking about the net distro and refuse
> >> to support the non-net distro installation.  The point made on the list
> >> in that case is "use the net distro, luke".
> 
> The situation I'm talking about is where someone is reporting a "cygwin
> problem" which turns out to be from a cygwin1.dll stashed somewhere
> unobvious on their path.  Currently it's more likely that we'll detect
> this than it would be if we allow multiple copies of cygwin.
> 
> >Having said that, I guess the point of keeping this optional is to allow
> >to change the behaviour at all, if some situation arises in which this
> >is an advantage.  So, I'm fine with making this optional.
> >
> >I still think, however, that, even if we make it optional, the default
> >should be switched on.
> 
> If it is turned on then I see little reason to switch it off except for
> the case of a paranoid installation which wants to enforce the
> one-cygwin rule.

No, if it is turned on, you have the advantage of having no more
collisions in most cases.  In the rare cases where there might be a
collision, you can ask the user to turn it on and re-check.

> >And I'm still not sure about the best way to set the option.  A
> >configuration file will slow down Cygwin's startup somewhat more.  Using
> >the registry for that doesn't have appeal either.  Would a CYGWIN option
> >not really make most sense?
> 
> We were talking about modifying a section in the dll itself.

This is unnecessary complicated.  The CYGWIN option is much easier to
use for the user, *iff* at all necessary.


Corinna

-- 
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]