[Build-common-hackers] Bug#461513: Bug#461513: cdbs: requires aclocal.m4 to be present in order to generate it
dr at jones.dk
Thu Mar 19 20:05:51 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, Mar 19, 2009 at 01:40:41PM -0400, Evan Broder wrote:
>> Note that the variable is called DEB_AUTO_UPDATE_ACLOCAL, not
>> DEB_AUTO_CREATE_ACLOCAL, so the feature works as designed.
>Is this actually in any way a useful design? I can't think of any
>scenarios where a maintainer would explicitly set
>DEB_AUTO_UPDATE_ACLOCAL and not mean for aclocal to get run.
>On the other hand, I can think of a couple of cases where aclocal.m4
>might not already exist - braindead upstream being the most obvious.
>Alternatively, I've had packages where I patched the upstream source to
>the point that I needed to run aclocal after patching.
>DEB_AUTO_UPDATE_ACLOCAL isn't something that's set automatically, or
>accidentally. It doesn't make sense to me for CDBS to try and
>second-guess the package maintainer like this.
I agree with Evan.
The way I interpret the name of the option, it is not only about
updating the aclocal.m4 file, but about updating the aclocal part of
autotools, chich may involve creating its .m4 file.
Similarly with the other parts of autotools: I see no reason for
protecting the packaging routines against something explicitly
Please provide some more substantial reasons for keeping current
behaviour - like examples of what could break without those "safety
checks" in place. I'll wait a bit, and then drop those checks - for all
autotools, not only ACLOCAL.
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Build-common-hackers