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

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

cgf


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