[Build-common-hackers] Bug#461513: Bug#461513: cdbs: requires aclocal.m4 to be present in order to generate it

Jonas Smedegaard dr at jones.dk
Thu Mar 19 20:05:51 UTC 2009

Hash: SHA1

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

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
Version: GnuPG v1.4.9 (GNU/Linux)


More information about the Build-common-hackers mailing list