Avoid collisions between parallel installations of Cygwin

Larry Hall (Cygwin Developers) lhall@cygwin.com
Fri Oct 16 17:16:00 GMT 2009


On 10/16/2009 05:52 AM, Corinna Vinschen wrote:
> 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.

So your argument is that the current situation isn't discouraging anyone from
distributing their 3PP using Cygwin?  I would think that would be a strong 
argument
for making such a change.  Earlier comments from Earnie regarding some packages
that used to be Cygwin-based and are now MSYS-based seem to support this idea.
I have to admit that I, personally, don't have any data on this.  Still, I 
would think
that this change will encourage more 3PP and, even if not, more users, since 
collisions
should fade into the background as an issue.

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

OK, I see what you're saying.  If the message wasn't popping up in these cases,
that may be a bug, but in any case it suggests that it hasn't been helping 
the users
as much as intended.

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

Actually, I think I conflated two points when I didn't mean to.  There may 
be allot
of overlap between the MSYS and Cygwin user bases when it comes to people
actually installing and using these products as the products.  I'm less 
concerned
about this group, since they are probably more knowledgeable.  It's the 3PP 
product
(based on MSYS or Cygwin) users that I'm focused on.  As you mention, this 
is the big
bunch of folks that aren't at all tolerant of platform (with Cygwin being 
the platform).
And I guess the real question is - does this change cause this group and their
application options to grow and will the experience for us and them be more 
positive
as a result of this change?  And I don't know the answer to that.

I know the intent here is to make using Cygwin, in whatever form, better for 
everybody.
Since there hasn't been allot of talk so far about issues that aren't 
already addressed
by your patch, I take it that people don't see any show-stoppers hiding in 
this.  And
that's good.  But it's clear (to me at least) that this is a big change, so 
that's why I
keep coming back to the "How can we be better prepared for it?" question. 
So, I guess
what I'm saying is that I don't think this is a separate point of discussion 
(in my mind)
but rather an offshoot of my original second point. And maybe we've hit the 
wall here. ;-)


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?



More information about the Cygwin-developers mailing list