This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: setup revisit
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-developers@cygwin.com>
Sent: Saturday, March 24, 2001 12:46 PM
Subject: Re: setup revisit
> On Sat, Mar 24, 2001 at 11:44:27AM +1100, Robert Collins wrote:
> >> > 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.
> >>
> >> If the bootstrap is a tarball, you need tar and gzip outside that
> >> anyway. If you have that, why not just use it to install *all* the
> >> tarballs?
> >
> >Because
> >a) you cannot add (for example) bzip2 without changing setup -
porting
> >bzip2 to raw win32
>
> I know that you are just giving an example but porting to use bz2
would
> be pretty trivial these days.
Uhmm, trivial without cygwin1.dll ? I presume thanks to the work at the
mingw project.. Next example: rpm (depends on sleepycat db (raw win32
only builds in MSVC at the moment) and possibly perl.
If you meant porting bz2 with cygwin1.dll, well that's the whole point:]
> >Cool. I believe I can keep the overhead within 20% of the original -
by
> >splitting out the bootstrap tarball and using the separate files as
part
> >of the download cache.
>
> You still have cygwin conflict issues. We used to have to say "Stop
all
> Cygwin programs" but, surprise, people didn't do this and were
confused
> on the mailing list.
Actually you *still* have to say that. I get caught by cygipc.exe on a
routine basis - and I hope I'm not your average newbie. You will
*always* have to say that until whatever is trying to replace
cygwin1.dll / bash to name the most probable culprits is able to do
"behind the scenes" work. See my comments re replaceing files on reboot
for a long term solution.
> At any rate, this sounds like a long-term goal for setup.exe not a
short
> term one. I was hoping that someone could add some simple dependency
> analysis to setup.exe and come up with some way of grouping things
> by category. That should be relatively simple compared to redoing the
> entire installation to use apt or rpm.
>
> cgf
>
True. I was hoping to put my nose down and hack all weekend, but it
looks like rpm is *not* going to play nice so I'll give it a slightly
lower priority for now.
Rob