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

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
like Earnie isn't aware of anything on the MSYS side.  I think that does
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
that's more likely to be bitten by any issues that pop up and end up on the

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

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