Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Fri, 23 Mar 2001 18:49:45 -0500
Message-Id: <200103232349.SAA03971@envy.delorie.com>
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: robert DOT collins AT itdomain DOT com DOT au
CC: cygwin-developers AT cygwin DOT com
In-reply-to: <00af01c0b3f0$e751e200$0200a8c0@lifelesswks>
	(robert DOT collins AT itdomain DOT com DOT au)
Subject: Re: setup revisit
References: <009201c0b373$270a6ee0$0200a8c0 AT lifelesswks> <20010323174032 DOT A30954 AT redhat DOT com> <200103232258 DOT RAA03576 AT envy DOT delorie DOT com> <00af01c0b3f0$e751e200$0200a8c0 AT lifelesswks>


> I'm against the idea of building "intelligence" into setup.exe (making
> it the 33rd packaging and distribution format).

The intelligence is in configuring a valid cygwin setup, not unpacking
a standard tar.gz format.

> So, the question becomes (for me :] ) how much effort will be required
> to port rpmfind and rpm to win32, as statically linked libraries that
> setup.exe can use.

RPM has already been ported to cygwin, I don't know what it would take
to port it to raw win32.

> Ah, just had an insight into the GPL issues - which if I guess right
> means that I cannot port and use rpmfind??

No, it meant that any copy of setup needed the sources to gzip and tar
to be distributed with it.

> What GPL issues am I going to run into?

Distributing sources to not only the setup program, but any other
programs embedded in it.

> In summary, if for a given route the GPL issues mean I cannot leverage
> an existing packaging & distro format, I'm not interested in taking that
> route.

Quite the opposite.  The GPL *guarantees* that you can leverage
existing software.  However, complying with the GPL when multiple
programs are involved, especially when there are slightly different
versions of those same programs in the tarballs, is cumbersome.

> Why instantly obsolete?

setup includes version X of cygwin1.dll.  Tomorrow, version X+1 is
released.  Now you can't run setup while any other cygwin program is
running, and setup is using a version of cygwin different from what it
is installing.

> If the bootstrap is a separate tarball that it checks for (like it
> does setup.ini), then the core engine is going to stay the same for
> a looong time.

If the bootstrap is a tarball, you need tar and gzip outside that
anyway.  If you have that, why not just use it to install *all* the
tarballs?

> How often does the rpm format change (ok trick question :] rpm is
> rather volatile). More important question: if I take the ported rpm
> 3, and use the patchs to port rpm 4, then we can sit there without
> headaches...

I've found it hard to migrate from RPM 3 to RPM 4 on *Red Hat Linux*.

> As far as size goes, I can look into ways to make that the bootstrap
> smaller - I've got some thoughts there. It's going to be a lot smaller
> than a linux bootstrap environment :]

It went to 10% of its original size when I changed it.