Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Tue, 23 May 2000 12:48:44 -0400
Message-Id: <200005231648.MAA22998@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: rdparker AT butlermfg DOT com
CC: cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to: <200005231623.MAA17712@delorie.com> (rdparker@butlermfg.com)
Subject: Re: setup: built-in tar
References:  <200005231623 DOT MAA17712 AT delorie DOT com>


> I am sure you are aware of this, but part of the reason for using
> the actual tar.exe was because it was a cygwin program and
> automatically dealt with soft links, hard links and mounts properly
> for the current OS/FS combination.

Part of the problem with this is that it's dependent on the user's
system being set up properly.  Other problems include:

* tar and gzip are GPL; we have to ship the sources for them with
  every setup.exe.

* tar and gzip rely on cygwin1.dll; setup would be more reliable if it
  could save that file with a unique name (say, setup-cyg.dll) so that
  you can run setup while a different version of cygwin is running.

* Using an internal tar means we can defer changing the mounts until
  the files are installed, in case something goes wrong we don't end
  up leaving the user with a broken system.

* tar.exe has a number of pre-concieved notions about how faithfully
  it should restore files to disk.  When setting up cygwin, we may
  want to override those in ways which are difficult for tar.exe to
  do.

* It's difficult to display progress indicators (GUI) when we have no
  control over the extraction process.

> Are we taking into account text vs binary mounts, binmode vs
> nobinmode,

Setup should never rely on text v binary mounts.  It must always force
one or the other itself.

> ntea vs nontea, ntsec vs nontsec, FAT vs NTFS, etc?

None of these should be an issue with standard installed packages,
because those packages must work in all environments anyway.

> > This built-in tar also allows setup to more closely
> > control where files are going; it can ignore conflicting mounts the
> > user has set up in favor of what it knows is right, for example.
> 
> If I may be so bold, who are we to say what is "right".

We are creating cygwin, and we are supporting it.  If the user does
something different and we break, whose fault is it?  I'd rather that
setup guarantee a valid installation and let the user muck with it
afterwards, than let setup take a chance with a random user
configuration.

> God knows I am not a relativist, but if a person has gone to the
> effort to setup specific mounts for their specific needs, who are we
> to say they are wrong?

If we want to support random mount points for the core installation,
setup should handle it.  Maybe it can read the mount table or
something - that's no big deal.  As it is, setup already removes a
whole bunch of mounts and creates its own.

> Of course this in just IMHO.

Of course.

> Is there an actual problem here that you are trying to address or is it to
> simplify the tar-like code?  I am just wondering about the motivation.

Besides the reasons listed above:

* TCL installs a number of read-only files that we had to hack the
  installation to deal with because tar couldn't.

* I'd rather not rely on third-party programs in setup (call me
  paranoid).

* Integrating them makes setup smaller and faster.

* Why run a program when you can call cygwin1.dll directly?

* GUIs and spawned programs don't get along well.

* Protection against rogue packages overwriting critical system files.