Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Message-ID: <3C6EB068.CE60F69A@windriver.com>
Date: Sat, 16 Feb 2002 11:18:00 -0800
From: Doru Carastan <doru DOT carastan AT windriver DOT com>
Organization: Wind River, Inc.
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Registry freedom
References: <1013760405 DOT 2121 DOT ezmlm AT cygwin DOT com> <3C6DF94A DOT 2079DCC0 AT windriver DOT com> <20020216162734 DOT GB25836 AT redhat DOT com>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 
> On Fri, Feb 15, 2002 at 10:16:42PM -0800, Doru Carastan wrote:
> >Hello everybody,
> >
> >I believe it is time to break free from using the registry. It doesn't
> >allow for multiple versions to coexists, which creates a nightmare when
> >it comes to packaging Cygwin with another product.
> 
> Hmm.  Packaging Cygwin with another product?  Sounds like you need to
> talk to our sales department.

Not necessary. Actually is packaging WITH another product. Cygwin is
used as an enabler for rpm. rpm is the main tool of a cross platform,
package based, product install SDK that on Win32 hosts helps me be MS
Installer free. The only application linked against cygwin1.dll is and
encryption/decryption tool derived from mhash and mcrypt for which
source will be available together with the Cygwin, rpm and other GNU
tools used. I'll have someone talk with your sales before we release
anything to check things. If justified, buying a commercial license it
shouldn't be a problem.
 
> [Insert obligatory warning about GPL here]
> 
> >I've been rebuilding cygwin1.dll for a while with a custom shared memory
> >id and registry section and I know that it is possible to have a given
> >cygwin1.dll version coexist with its modified clone. Why not using
> >GetModuleFileName() to retrieve the path to the dll and look around it
> >for an mtab like ASCII file. Once the DLL path is retrieved the mtab
> >file can be searched in $dllDir/../etc/:$dllDir. If it is missing then
> >assume that there are no custom settings and use the defaults.
> >
> >I wonder if this can be done. Does anyone see any technical problems?
> 
> Of course its *technically* doable.
> 
> The biggest problem is technical support.  Now that you've set things
> up so that you can have 27 different versions of cygwin on your system,
> you'll have compounded our technical support alarmingly. I'm not going
> to do this.  This isn't that big a problem for the normal release of
> cygwin.

Cygwin and a minimal set of GNU packages is all what it gets installed.
I was seriously considering the impact to your support efforts. That is
why a private installation is needed.
 
> I can see why Wind River might have a problem since apparently you're
> basing your Windows offering Red Hat's technology.  You probably don't
> want to have to install your software into an existing commerical
> directory that has the name "redhat" or "cygnus" in it.  However,
> accomodating that really isn't a goal that I am very interested in.

You are making a false assumption. The Cygwin + custom GNU tools
installer I created installs this tools for system wide use by various
product installers.  The default location is %SystemDrive%\wrtools to
avoid cluttering an existing C:\cygwin.  Some users might have various
versions and is not a good practice to mess up what they have.  I really
don't want folks to be creative and make changes to the stuff I rely
on.  They can play with c:\cygwin if they want to.  I also advocate the
slogan "you package it, you maintain it".  

When the user starts a WR product installer he/she will be prompted for
a location to install for that media. The product install dir has no
connection whatsoever with the location of the Unix emulator providing
the POSIX API.

Obviously you have total control over your distribution. Probably other
developers will see the value and be more open to this since it can
simplify the debugging process.
 
> If you want to make your own version of cygwin available and package it
> with your now-GPLed product then, as you know, you have the power.  Just
> make sure that no technical support shows up in cygwin AT cygwin DOT com.

Linking our products against cygwin1.dll is not the goal, neither use of
setup.exe. It's all about packaging and delivering. Our products
documentation clearly states how to get support. See
http://www.windriver.com/corporate/html/tsmain.html for more info.
 
> Regardless, I really don't see the problem.  You don't need to install
> multiple versions of linux on your system to accommodate different
> programs.  It is a little trickier on Windows but it is still not that
> hard to do with the right installation software.

I just can't wait to see Cygwin stable enough to bet the farm on it.
Unfortunately it is still on the bleeding edge with major changes every
3 months or so. We all know that it takes a lot of time and effort to
add features and stabilize the code. Until then one can only isolate and
use something perceived to be stable.

> Of course, this is the same observation that I make whenever someone has
> this interesting new idea.
> 
> cgf

Sincerely,
Doru Carastan

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