This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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
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?