Jeremy Bicha wrote: > On Fri, Nov 16, 2018 at 2:26 AM Yavor Doganov <ya...@gnu.org> wrote: > > > Using autoreconf is part of the solution. Usually though, autoreconf > > > prefers macros in the source over system copies. So if your source still > > > contains the (outdated) copy, autoreconf will prefer it. > > > > That's not true if autoreconf is being run with the --force option > > (which dh_autoreconf does); all files are considered obsolete then. > > In my experience, Helmut is right.
No, in this particular case he is not right; you are both confusing two different use cases that have different (documented) behavior. The --force option causes the output file (aclocal.m4) to be generated always. If the package is not shipping the third-party macro (as is the case with grdesktop -- it is not shipping pkg.m4), --force will always recreate aclocal.m4 using the macro definition as found in aclocal's search path (or autoreconf will fail if it cannot find it). IOW, it is not necessary to patch aclocal.m4 as it is always going to be regenerated by dh_autoreconf. > So in some of my packages, I've been adding the autoconf macros to > Files-Excluded so that they aren't part of the Debian source when > importing new tarball releases to ensure we actually build from the > latest sources instead of sometimes ancient macros. This happens when the package ships convenience copies of third-party macros in the directory defined by AC_CONFIG_MACRO_DIR. In this case you are both right that --force will not replace these macros with the ones from the system. "aclocal --install" will do (respecting the serial numbers so it won't downgrade macros); the other option is to delete the files as you have been doing. However, this sometimes results in regression if the package was bootstrapped by the upstream maintainer with a newer version of the package providing the third party macro than the one in Debian. (Happens all the time with packages using gnulib as it's almost always outdated in Debian.)
