Mail Archives: cygwin-developers/2001/03/23/19:52:01
----- 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
- Raw text -