[Build-common-hackers] Bug#744915: Bug#744915: cdbs updating of config.{sub, guess} is not automatic on buildds

[Jonas Smedegaard]

Quoting Wookey (2014-04-16 10:44:45)
> CDBS provides functionality to automatically update config.sub and 
> config.guess for autotools-using packages during the build. This is 
> good practice and there is growing consensus that this should be 
> automatic for Debian packages (although it is not yet policy).
> 
> However this update only occurs if autotools-dev package is installed 
> so that current versions are available in the debian canonical 
> location.
> 
> autotools-dev is only 'Recommended' by cdbs so on buildds it is not 
> installed during a build, so CDBS-using packages fail to build on new 
> architectures if their autoconf files are out of date (and very many 
> are).
> 
> This could be fixed in two ways. 
> 
> 1) Make every CDBS-and-autoconf- using package build-dep on 
>    autotools-dev, or
> 
> 2) make cdbs depend on autotools-dev.
> 
> It seems to me that packages that use CDBS are doing so party because
> they expect it to take care of this sort of thing. And it does when
> they test on their local system, where apt will install 'recommends'
> by default. But it will (quite subtly) fail to take care of this on
> buildds (or in local sbuild chroots but they won't notice because
> thier chroots are very unlikely to be for the affected new
> architectures so builds will still work) because those are set to not
> install recommends by default.
> 
> I think the right fix for this is simply to make autotools-dev a
> proper dependency of CDBS, and not a recommends. Is there any real
> reason not to take this step?

Purpose of CDBS is not to automagically do $stuff, but to offer common 
practice templates for package maintainers to conciously use.

I acknowledge that recommending autotools-dev can be misleading, but 
that's better solved by only suggest it: Packages using CDBS but not 
autotools certainly are not "unusual" (cf. Debian Policy §7.2).

If CDBS were to declare dependency on the tools the source package may 
benefit from but have not declared a build-dependency on, then the list 
would be far longer and pull in OpenJDK and Qt.  That makes no sense.

If autotools-dev is to be treated special, then the more appropriate 
would be IMO to include it as dependency of build-essential.


NB! I should also mention that 1) is already in place (just not by 
default - updating build-dependencies during regular build is 
forbidden):

 1) Copy debian/control to debian/control.in
 2) Add @cdbs@ to Build-dependencies in debian/control.in
 3) execute this (or any other build rule with same var set):

    fakeroot debian/rules clean DEB_MAINTAINER_MODE=1

Result varies based on the CDBS snippets included in the debian/rules 
file - specifically when autotools.mk is included _and_ CDBS detects 
existence of config.guess/config.sub, package is updated to declare a 
build-dependency on autotools-dev.

For those not using above semi-autoresolving of package relations, 
there's hope too: I have recently improved handling of warnings in CDBS 
and hope to extend that to spit out a warning early in builds about 
autoresolved but unapplied package relations.


Sorry that I don't agree with your quick fix.  For (I guess) your main 
concern of having autotools-dev applied even when package maintainers do 
not care to add the needed build-dependency, I recommend you to try get 
that package part of build-essential explicitly rather than "sneak it 
in" by having cdbs or debhelper depend on it.


Regards,

 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20140416/3cea3eee/attachment.sig>