This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setup revisit


----- Original Message -----
From: "DJ Delorie" <dj@delorie.com>
To: <cygwin-developers@cygwin.com>
Sent: Saturday, March 24, 2001 9:58 AM
Subject: Re: setup revisit


>
> > When DJ rewrote setup.exe he opted not go go this route.  Maybe he
can
> > reiterate his reasons for doing this.
>
> It was way bigger than it needed to be.  It was likely to become
> instantly obsolete.  It was often incompatible with already-loaded
> DLLs. There were GPL issues.
>

I'm against the idea of building "intelligence" into setup.exe (making
it the 33rd packaging and distribution 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. Ah, just had an insight into the GPL issues - which
if I guess right means that I cannot port and use rpmfind??

What GPL issues am I going to run into? The Redhat need to dual licence
the resulting tool? Howabout I leave the existing setup alone, except
for the ability to do a bootstrap IFF it's built with a given #define?
Then all the bootstrap code goes in a different directory, and is GPL
only licenced. My idea being that your commercial customers who are
getting a minimal fixed set install _anyway_ don't need and won't
appreciate flexible package and dependency tools.

<soapbox>

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. I'm happy to contribute code _I've written_ to redhat, so that
the cygwin I use gets better. I'm just not interested in finding new
solutions to already solved problems. I am interested in getting an
existing solution onto win32 via porting however.
</soapbox>

Why instantly obsolete? 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. 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...

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 :]

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]