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
