Mail Archives: cygwin-developers/2000/05/23/12:48:57
> 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.
- Raw text -