Subject: Re: Multiple cygwin installs: I have to do it, but how?
From: "Robert Collins" <[email-masked]>
To: "Peter Buckley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Fri, 12 Oct 2001 10:09:28 +1000

----- Original Message -----
From: "Peter Buckley" <[email-masked]>
To: "Robert Collins" <[email-masked]>

> > There is no reason for vendors that distribute copies of
cygwin1.dll -
> > the net release with source - to spend man-weeks fiddling around to
make
> > everything separate. All they need to do is ship the cygwin1.dll
with
> > the cygwin setup program and a local cache dir already created. Then
for
> > their specific apps - say gcc + scripts - all they have to do is
> > integrate them the *same way* they would on a unix system. No
problem,
> > no fuss.
>
> This seems to be a bad deal for vendors. They get stuck with a lot of
> support costs when people call up saying "how come your product
doesn't work
> anymore?" after they have updated cygwin out from under the vendors's

And they paid how much for cygwin? $0.00. Same deal as Linux. I just
installed Redhat 7.1 and <foo> no longer works. I don't see Redhat
pushing for a
multiple-kernel-and-libc-of-the-same-major-version-on-a-box capability
in Linux. If they were perhaps the the Hurd would be getting more
popularity. Also note that the Hurd *still has* a core kernel that
cannot be duplicated at runtime.

> products. "Oh, just reinstall our software, it will downgrade your
cygwin
> and you'll be all set." That doesn't seem like it would work well.

Some vendors have tried that with Linux based products from time to
time. Some still do. Then it becomes a user choice as to whether to buy
from that vendor or not.

If the vendor wants to put the investment into making a separate install
for their users *It is already supported at build time*. Of course it
will not run with the bash shell I can download from cygwin, so what,
the vendor is doing a special-build just for their product. I understand
that.

I guess I just don't understand the attraction of having parallel
installs of cygwin at run-time.

* It's more complex to code.
* It _will_ be slower. (think redirection dll with forwarded exports lay
er to load the 'instance'). Then multiply that by the number of fork()
&& exec() calls during a make.
* It will be more prone to breakage. "I can't use procmail on my
system. - Have you installed cygwin form cygwin.com? - Yes, but I
skipped cygwin1.dll cause I already have one from <vendor> - That's not
supported we don't know what they have done to it. - But when I install
your one everything is slower - Yes, thats by design!"

* Build time parallel installs are already implemented and work!

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/