Package: lintian Severity: wishlist User: helm...@debian.org Usertags: rebootstrap
Chris asked me to file this vague idea as a bug to keep track of the discussion. If the discussion winds down, please don't hesitate to close this as wontfix. While making packages cross buildable, I noticed another *very* common fix pattern and I am wondering how to automate it. The pattern is actually multiple ones: * s!\./configure !dh_auto_configure -- ! * s/cmake /dh_auto_configure -- / * s/qmake /dh_auto_configure -- / * s/\$(MAKE)/dh_auto_build --/ The reason why this helps is that debhelper has knowledge of cross compilation in many cases. It passes additional flags for each of these commands. Now it's not quite as simple as depicted here. Let me share some experience and explain corner cases. * Some ./configure scripts are very old or not generated by autotools. In such cases, dh_auto_configure may be unusable, because it passes unrecognized flags. * When applying any of these, one must add "debhelper (>= 7)" to Build-Depends. * When converting ./configure, it is often useful to drop redundant flags such as --prefix=/usr --mandir=... --infodir=... and others. * Depending on the compat level, dh_auto_configure passes a multiarch --libdir which might not work with a package immediately. * When doing out-of-tree builds with autotools, one usually uses "cd builddir && ../configure ..." and that should be translated to --builddirectory. Sometimes though it is "cd src && ./configure ..." in which case, it needs to be --sourcedirectory. * For cmake, most packages use out of tree builds (with a different directory name from debhelper) and thus often requires --builddirectory. * When substituting $(MAKE), be careful to distinguish dh_auto_build and dh_auto_install. * Some packages have multiple build systems and need to explicitly select one. You'll find lots of example patches at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=rebootstrap;users=helm...@debian.org Check only ones with "FTCBFS", "build architecture" is a good title filter as well. If we add something like this, I think it cannot be above certainty possible, because there are so many cases, where this choice has a good reason. This is certainly not a "copy & paste"-kind of advice, but one where the packager needs to think about the implications. It's more akin to "please increase the compatibility level", which can break in similarly subtle ways. Additional benefits (or caveats): * For some build systems (e.g. cmake) dh_auto_configure automatically passes dpkg-buildflags. * For the makefile buildsystem, dh_auto_install tries to prevent stripping (in higher compat levels) to get useful -dbgsym packages. In any case, the real lesson learned here is that our tool diversity has a significant cost. In a sense, a lot of my patches have converted packages to become more standard debhelper packages. Such uniformity lets us eliminate whole bug classes with little changes and that's something I've used a lot as at least Niels knows. I had to replicate a few of these for cdbs. From this experience, I think that we should more aggressively try to move away from tool diversity. Other areas (such as maintainer script removal or R³) also benefit from decreased tool diversity. Now it reads more like this mail should have gone to d-devel. Can we turn this into something useful anyhow? Helmut
