This is the mail archive of the
mailing list for the Cygwin project.
Re: recoverable downloads - opinions sought
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Robert Collins <robert dot collins at itdomain dot com dot au>
- Cc: cygwin-apps at sources dot redhat dot com
- Date: Sun, 25 Nov 2001 03:43:32 -0500
- Subject: Re: recoverable downloads - opinions sought
- References: <093e01c1745c$aece3f50$0200a8c0@lifelesswks>
Robert Collins wrote:
> To do recoverable downloads we need 2 things.
> 1) A way to check the file, other than filesize, for integrity. MD5 will
> do and IIRC that's already caclulated on sources.redhat.
> 2) Code to pickup partway through and carry on.
> For 2) we can either code it internally, or link statically to something
> like libcurl, or call out to wget/curl.
But if setup used an external library (or program) it would have to be a
non-cygwin version, right?
> My current mental state:
> For creating a mirror aka download only, we have to run on a cygwin-free
> system with little or no loss of functionality. Imagine someone on a
> corporate network with a dedicated 'net' PC, and cygwin not allowed on
> 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.
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. ;-)
> 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.
Might as well just update setup.exe itself, then, if you're going to do
it manually. Therefore, static link.
> 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.
Yep. Might be helpful to review the arguments surrounding Dario's
proposal (which he backed up with an actual implementation and, like,
documentation and stuff).
Thread: July, "SETUP WIZARD FOR CYGWIN?XFREE86" firstname.lastname@example.org
Thread: July, "RE: RPM installer (was Re: SETUP WIZARD FOR
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...
anyway, I'm just rambling now.