On Sat, 8 Dec 2012, Jim Meyering wrote:
I just encountered new argument for providing .gz of autoconf also in
the future.
There is no tangible benefit offered to the world by removing the
gzip-compressed autoconf package. Xz is excessively complex,
excessively large, and has limited portability and stability compared
with gzip.
Hi Bob,
I don't know of significant portability problems.
In my experience, if they are reported and affect significant
(sometimes even insignificant) portability targets, they will be
addressed promptly. Can you point to reported problems that
have not been resolved?
As far as I am aware, xz still fails to link successfully under x86
(x86-64 kernel) Solaris when built with GCC since xz requests to build
the objects with some special addressing model. This is a well known
issue (see
http://sourceforge.net/projects/lzmautils/forums/forum/708858/topic/3500014).
The documented workaround does not work properly. In order to
circumvent the issue, I had to use the commercial Oracle compiler. I
have not encountered any other software with this sort of issue.
There is no shortage of reasons to avoid gzip these days. One that
strikes home for me (as a package maintainer) is that there have
been exploitable CVEs against gzip in the recent past, and the code
is surprisingly ugly (hence hard to audit). I do not want to require
This may indeed be true. However, if autoconf itself stops using gzip
then the effect on the world will be imperceptible except that people
who want to install autoconf and who don't have 'xz' will suffer. If
Automake (and GNU tar) was to refuse to create gzip archives, and new
gzip releases could only decompress, then there would be noticeable
impact.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
