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 15 13:40, Larry Hall (Cygwin Developers) wrote:
>        So I expect that whatever solution we come up
>      with will increase the number of possible cases for multiple Cygwin's 
> allot.

Frankly, I don't think so.  The reason to provide a package with an
underlying Cygwin DLL are in most cases the chance to provide some
arbitrary functionality which is based on the POSIX API.  The number of
3PPs providing a small OpenSSH package are a rather good example.
These use cases don't change just by providing a DLL which doesn't
collide anymore with other DLLs.

>> I don't quite see the problem.  Many "multiple Cygwin" problems on
>> the list started out with an error description which wasn't very
>> helpful, unless, in the second or third reply, there was the hint that
>> the tool was installed from the "Nifty-Difty Ultimate SSH" site.
>> And it was very certainly not always combined with a simple "multiple
>> Cygwin" error message.
>
> True but it was obvious to ask for a 'cygcheck' and to tell the poster to
> look for multiple DLLs.  And the message was there for the user to indicate
> the problem and a possible solution.  Of course, the scenario above wouldn't
> happen currently.  The multiple DLLs complaint would either show up when
> trying to run or the 3PP would "just work".  So I see this as one of multiple
> potential new vectors that we will start seeing.

I'm not sure I get you there.  What I was trying to say is, if you look
through the cygwin list you will find a couple of interesting problem
reports, in which only cygcheck provided us with the information that
multiple Cygwin DLLs existed on the system.  There was no multiple
Cygwin message, just some weird effect.  I dont want to devaluate the
multiple Cygwin check, but it just can't be entirely bulletproof since
there are so many ways in which a complex system we have no control over
("Windows") can go wrong.

Having said that, sure enough, we will trade some sort of problems
with other sorts of problems and it's certainly not yet exactly clear
how these new sorts of problems will manifest.

>> There are two possible outcomes.  Either the Cygwin DLLs are happy with
>> each other since they are running basically the same version of Cygwin.
>> In this case the above problem just doesn't occur since piping still
>> works as expected.
>
> Yep.  Thanks for pointing this out.  It is an important point that I 
> glossed over.
> Of course, if this is one of those times when the 3PP needs it's DLL or Cygwin's
> 'cat' uses something new in Cygwin's DLL, this could still be a problem.  And
> although we run that same risk now if the 3PP delivers their own DLL, if we
> change the policy to allow multiple, coexisting DLLs, there may be a perception
> that we should allow this as well.  So we'll have to be prepared for that. 
> Again,
> besides the possible perception change, this doesn't seem like a new issue 
> really.

I agree.  The perception might change.  But it wouldn't be an entirely
new thing having to argue why something doesn't work as expected.  The
expectations of users are often different from our expectations, simply
because we know (or have a gut feeling) about limitations in what we're
trying to provide.  But, yes, we will have to be prepared for a new type
of explanations.  Keeping the FAQ in good shape might help.

> Yeah, I don't recall allot of complaints reported to the Cygwin list and it 
> sounds
> like Earnie isn't aware of anything on the MSYS side.  I think that does 
> provide
> some support for the idea that this kind of change isn't going to make large
> waves in the user community.  Of course, no guarantees. ;-)  And we also have
> to consider the differences in the size and clientèle in these two communities.
> I'd wager that the typical MSYS user is not a newbie trying to learn about Linux
> or someone that just wants to check out a cool new packaged app.  I'm betting
> we will see more users of this ilk on the Cygwin side and that group is the 
> group
> that's more likely to be bitten by any issues that pop up and end up on the 
> list.

I doubt that the user bases of MSYS and Cygwin differ a lot.  If there's
a difference, it's about the hardcore users using either platform for
development and stuff like that.  But there's a big bunch of users out
there who use the platform without being interested in the platform
itself.  They care for a tool or two, but they have no interest
whatsoever in the way it's implemented.


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]