Re: [Bug-tar] --auto-compress command line option

[Helmut Waitzmann]

Denis Excoffier <address@hidden> writes:

>Taking into account your not-completely-full support of my original proposal
>(with several relevant arguments, i must admit) let me modify it a little
>bit. I suggest:
>
>1) that the location of the compress/gzip/bzip2/lzma programs to be
>settable at configure time, under one (or four) optional command line
>option(s)
>of ./configure
>
>AND
>
>2) that the tar executable uses these locations (when set) only if given the
>new --use-locations-defined-at-configure-time command line option 

Please, supply a complementary option (to switch that behavior off,
again, should it have been switched on), too.

>(please select a shorter name); otherwise, the usual PATH method is
>used; if the location defined at configure time is not usable (not
>found, not executable etc.), same behaviour as when
>--use-compress-program is in the same position.

I've no objections to your proposal.

However, I must admit, that I don't see a need to set the location of the
compress programs at configure time.

Let me explain, why:

If the compress programs wouldn't be found by a path search, then
probably not only the environment variable PATH is not configured
properly.  So rather a login shell really should have been started in
advance to do a setup of the process environment.

Also, to configure the location of the compress programs won't always be
the solution to a problem with wrong compress programs:

Imagine a binary Linux distribution.  Tar is configured by the
distributors, not by the system administrator.  If a bug with a
compression program is revealed, then a system administrator might patch
the source of that compression program, compile and install it to
"/usr/local/bin/" (at least, til the distributor issues a patched binary
package of that compression program).

Installing it to "/usr/bin" rather than to "/usr/local/bin" wouldn't be
an alternative, because that would be overwritten by the original buggy
binary package, should it be reinstalled.

Now, if the distributor had configured tar to use the configure time
locations of the compress programs, that system administrator would have
to exchange tar by a recompiled, reconfigured version (of
cause in "/usr/local/bin" to prevent it from be inadvertently
overwritten), just to make it aware of the different location of a
compress program.  Then, each package, that knows tar by its full
path--for example an archiver package--would need that treatment, too...

As an alternative, rather than recompiling tar, the system administrator
could delete the option "--use-locations-defined-at-configure-time" from
the "TAR_OPTIONS" environment variable, which probably had been set in
one of the files "/etc/profile" or "${HOME}/.profile".

So, to have this environment variable been set, a login shell had to be
started in the first place.

If, on the other hand, tar is configured to just use the search path to
get the locations of the compress programs, no such recompiling would be
necessary.  Supplying the corrected compress program in "/usr/local/bin/"
and relaying on the PATH environment variable is all that would have to
be done.

To setup a correct value of the "PATH" and the "TAR_OPTIONS" environment
variable, a login shell can be started (which already has been done, when
logging in.)

Kind regards,

Helmut
-- 
Wer mir E-Mail schreiben will, stelle   |   When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen   |   precede my e-mail address with
Vor- und Nachnamen, etwa so:            |   my full name, like
Helmut Waitzmann <address@hidden>, (Helmut Waitzmann) address@hidden