This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: recoverable downloads - opinions sought
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> Robert Collins wrote:
> But if setup used an external library (or program) it would have to be
a
> non-cygwin version, right?
Not necessarily. Cygwin1.dll can be loaded dynamically.
> > Using an external helper, via a bootstrap process will be a lot
easier,
> > but will sacrifice the functionality when on a non-cygwin machine.
>
> You're assuming that the external helper is a cygwin program, I guess.
Yes.
> Ummm...I'm reminded of Dario's rpm-based cygwin distribution. He had
a
> bootstrap phase that installed cygwin(dll, bare minumum tools, rpm
> itself), and then used rpm to install everything else...
>
> If we're going to go with a two phase setup, then his idea makes more
sense
> than continuing to roll our own. The big argument against his plan was
>
> (a) two phase is bad (b) why throw away our perfectly good setup tool.
Okay,
>
> that's two arguments. ;-)
I don't think two phase is bad, but supporting the download-only version
on non-cygwin machines is the cruncher. As for b) I'm very much in
favour of setup.exe being the user interface - to whatever does the
dirty work, be that setup.exe or another tool.
> > So I'm in favour of internal code/static library linkage. A dynamic
> > library _could_ be used, but we'd ned to treat it as a special case,
not
> > as a standard isntall-and-log package.
>
> Yep. But if it's a special case, then we might as well link it in
> statically. If it were in a DLL, we can't update it on-the-fly from
> setup because setup.exe is still using it...so updates of that DLL
have
> to be done manually.
Exactly. (About the special case -> link static logic). As for updating
the .dll that's not a problem. Here's why. The .dll will not be in
setup.exe's import table so setup.exe can check the dll's version as the
first thing it does.
> > The alternative to internal/static code is to go down the path of
> > splitting setup into two builds, but as we'd _still_ have to get the
> > download-without-cygwin part right, I see no benefit in this.
>
> Also,
> http://www.cygwin.com/ml/cygwin-apps/2001-07/msg00074.html
>
> I seem to remember that in early september Dario actually put together
> an ISO that embodied his whole rpm-based cygwin dist including a
> tk/tcl-based 'bootstrap' installer...
Which was really neat. I should get that out an review it :].
Rob