Mail Archives: cygwin-developers/2001/03/24/01:20:10
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT cygwin DOT com>
Sent: Saturday, March 24, 2001 3:49 PM
Subject: Re: setup revisit
> On Sat, Mar 24, 2001 at 03:42:08PM +1100, Robert Collins wrote:
> >----- Original Message -----
> >From: "Christopher Faylor" <cgf AT redhat DOT com>
> >To: <cygwin-developers AT cygwin DOT com>
> >Sent: Saturday, March 24, 2001 2:25 PM
> >Subject: Re: setup revisit
> >
> >
> >> On Sat, Mar 24, 2001 at 02:19:32PM +1100, Robert Collins wrote:
> >> >
> >> >Oh. That wouldn't have affected what I was suggesting (the current
> >> >cygwin1.dll would be used unless an update was present - in which
> >case
> >> >it comes back to the current setup's behaviour.).
> >>
> >> And if the current cygwin1.dll is B20? Do you want to rely on
that?
> >> Or if it is a buggy snapshot?
> >
> >"unless an update was present". Then it upgrades cygwin1.dll first -
and
> >if it can't either gives the current cygwin1.dll upgrade failure
"can't
> >open", or [insert desired message/action].
>
> So you'd have a side channel, special case method for updating the
> cygwin DLL which didn't rely on the cygwin DLL? That sounds messy to
me.
>
> cgf
Less messy than having the distribution channel completely external to
the software package... (example: Change mount styles -> rebuild
setup.exe). And I'm not suggesting a special case _beyond the
bootstrap_. I'm suggesting that the bootstrap _be the special case_.
So the core - cygwin1.dll aka the "kernel" and rpm/tar/whatever aka the
"packaging system" get distributed via the side-channel (the current
setup.exe). I've been suggesting that unchanged right from when I
brought up bootstrapping. Everything else gets done by the packaging
system. As a reference point every system I've ever seen falls into one
of two camps:
A) A side channel for the _very core_ files and an elegant self-hosting
system for the rest of foo.
B) Distribution and setup is completely external to foo.
Installshield uses a bootstrap system. MS's Active Setup uses an
external system. RedHat's rpm falls into A) (How do you install the
kernel the 1st time? Not via rpm :] ). Windows update falls into A). MS
Visual studio falls into B). Most end-user software falls into B). Some
software (a growing number) fall into A) because they're including
"updaters".
Now I'll admin that in unix based environments you can upgrade the
kernel and the packaing system in-place, without trickery... but at the
moment we don't have that luxury. It's something I can and will attack.
If I succeed with that, we should be able to update cygwin1.dll from
within cygwin1.dll. Note: Like you, I'm not worried about the special
cases: users of snapshots & developers. Cygwin B20 is an issue though..
hmm.
All this is academic though - If we end up with a raw win32 packaging
system, then it doesn't really matter. And I'm willing to give porting
rpm a shot (not much luck so far :[ ).
Rob
- Raw text -