setup revisit

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-developers@cygwin.com>
Sent: Sunday, March 25, 2001 3:30 AM
Subject: Re: setup revisit


> If we change the mount style then many existing cygwin applications
> break.

I've got to find better examples :]

> >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".
>
> I like the consistency of setup.exe.  There is one method that updates
> everything.  You can do this because we rely on an underlying Windows
> OS being there.  Red Hat setup doesn't have that luxury.

It's nice, but only as long as everything comes from sources.redhat.com.
I can't use setup.exe to install XEmacs. (And yes I know they have
forked setup.exe to install XEmacs). RPM and it's ilk usually break the
'index' out from the files. This means that the XEmacs folk could just
give their endusers a new source for the index, and when the user runs
setup they see everything available from both sources. (Btw: this isn't
hypothetical - this is _how_ debian is installed - the whole OS. I
believe that rpmfind gives the same power. But as you've rightly pointed
out this is long term.

> We have discussed the issue of mount tables, etc., but given the
pledge
> of backwards compatibility that we have, I don't think this is an
issue.
>
> Maybe this really just argues for splitting the functionality that
> setup.exe needs into a separately loadable module that is used by both
> cygwin1.dll and setup.exe.

What's the issue with a static cygwin1.dll (can that code be moved out
and the rest linked statically with setup.exe ?).

> >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.
>
> snapshots != developers.  We ask end users to try snapshots.  We can't
> penalize them for doing this.
>
> cgf
>

Ok, I'll put my thinking cap on harder.

Rob