Bruno Haible wrote:
Jacob Bachmeyer wrote:
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without cooperation from upstream. If
m4/build-to-host.m4 had been recognized as coming from gnulib and
compared to the copy in gnulib, the nonempty diff would have been
suspicious.
True.
Note, however, that there would be some false positives:
True; all of these are Free Software, so a non-empty diff would still
require manual review.
libtool.m4 is often shipped modified,
a) if the maintainer happens to use /usr/bin/libtoolize and
is using a distro that has modified libtool.m4 (such as Gentoo), or
Distribution libtool patches could be accumulated into the set of "known
sources".
b) if the maintainer intentionally improved the support of specific
platforms, such as Solaris 11.3.
In this case, the distribution maintainer should ideally take up pushing
those improvements back to upstream libtool, if they are suitably general.
Also, for pkg.m4 there is no single upstream source. They distribute
a pkg.m4.in, from which pkg.m4 is generated on the developer's machine.
This would be a special case, but could be treated as a package-specific
m4 file anyway, since the developer must generate it. The developer
could also write their own m4 macros to use with autoconf.
But for macros from Gnulib or the Autoconf macros archive, this is a
reasonable check to make.
This type of check could also allow "sweeping" improvements upstream, in
the case of a package maintainer that may be unsure of how to upstream
their changes. (Of course, upstream needs to be careful about blindly
collecting improvements, lest some of those "improvements" turn out to
have come from cracker sockpuppets...)
-- Jacob
