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
Message-ID: <021801c0b3fb$97ff2d60$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "DJ Delorie" <dj AT delorie DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
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> <200103232349 DOT SAA03971 AT envy DOT delorie DOT com>
Subject: Re: setup revisit
Date: Sat, 24 Mar 2001 11:44:27 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 24 Mar 2001 00:38:57.0868 (UTC) FILETIME=[CFF798C0:01C0B3FA]

----- Original Message -----
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>
Sent: Saturday, March 24, 2001 10:49 AM
Subject: Re: setup revisit


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

Yes - and thats the intelligence thats in the apt* tools for debian, and
to a certain extent rpmfind for rpm packages.

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

Uhmm a bit. I'm looking into that now.

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

Whew, that does make it easier. (Hangon, setup.exe is GPL'd - why
doesn't the same issue apply to 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.

So, the link to download setup.exe sources, includes the source trees
for the embedded programs?

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

I made a erroneous assumption... forget my soapbox :]

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

I have a plan :] Two in fact.
1) Setup.exe keeps the current gunzip untar functionality - what it
needs to extract a bootstrap. Coincidentally, this means setup can
install updated cygwin1.dll/rpm.rpmfind binaries. Even easier:
setup.exe's menu list of packages is reduced to the bootstrap files (as
separate packages, reducing download repeats when upgrades occur). Then
"running setup" results in a list of 4-6 packages to install (and you
cannot choose uninstall or skip a a package). Once they are done, the
rpm based installed is launched within the cygwin environment.
2) I have done some work in the distant past on replacing open files on
reboot of windows. I can put that logic into cygwin1.dll (where the
deferred deletes happen today).. and have cygwin1.dll popup a message
box noting that the user will need to reboot to get the queued copy to
occur.

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

Because
a) you cannot add (for example) bzip2 without changing setup - porting
bzip2 to raw win32
b) installing is not the problem. The problem is dependency tracking and
package management.

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

Ah. So maybe rpm 3 is the way to go?

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

Cool. I believe I can keep the overhead within 20% of the original - by
splitting out the bootstrap tarball and using the separate files as part
of the download cache.

Rob