setup revisit

Robert Collins robert.collins@itdomain.com.au
Fri Mar 23 16:45:00 GMT 2001


----- Original Message -----
From: "DJ Delorie" <dj@delorie.com>
To: <robert.collins@itdomain.com.au>
Cc: <cygwin-developers@cygwin.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



More information about the Cygwin-developers mailing list