linux-ext4 - Re: Generated files in e2fsprogs git repo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJTo0Lb9cxfE4bt6qLXzg5C8_j-9MUtiE2se+PMbYSeE=Gjasw@mail.gmail.com>
Date:	Tue, 1 Jul 2014 10:55:51 +0100
From:	"Burton, Ross" <ross.burton@...el.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Generated files in e2fsprogs git repo

On 1 July 2014 02:02, Theodore Ts'o <tytso@....edu> wrote:
> I don't trust autoreconf.  Different versions of autoconf can end up
> with different incompatible versions of autoconf macros, and I have
> seen some rather disastrous failures as a result.  That's why I update
> autoconf under my control, and if you run autoreconf as a user, and it
> breaks because the "archaic macros" work, and the "new shiny" macros
> fail, that's your problem, and I will laugh at you....

I disagree with this position: if you're the one releasing the
tarballs then you have this control anyway - people building from git
have a higher level of technical competence assumed and using the
right versions of autoconf isn't rocket science.

My context is that we're building distributions and for every package
that uses autotools we forcibly autoreconf because the
upstream-provided configure is generally insufficient: for example
upstream libtool needs patches to cross-compile correctly, and there's
a long lag (several years) between a new architecture being developed
(two recent examples: x32 and aarch64) and it being wide-spread enough
to be in every generated configure script.

e2fsprogs is one of the handful that breaks when we do this, because
aclocal.m4 contains macros that don't come from the system (AX_TLS and
CHECK_GNU_MAKE).  Simply moving these macros to acinclude.m4 should
solve this problem for us: autoconf defines that aclocal.m4 contains
copies of macros from the system, but acinclude.m4 contains
project-specific macros.  I'll send a patch shortly to implement this
split.

Ross
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html