Re: Do we want to Require or Recommend DH
On Mon, 13 May 2019 at 15:57:34 +0200, Marco d'Itri wrote:
> I have already asked this last time, but nobody answered.
> I use debhelper in all of my packages but I have never switched to dh:
> why should I bother?
Here are some reasons you might want to consider.
When modifying those packages, a contributor (perhaps a NMUer, or perhaps
your future self) will have to think about questions like these, which
they wouldn't have to do if you were using dh:
- is this package invoking the various dh_foo helpers in the right order?
(e.g. if dh_one needs to be invoked before dh_two, not all packages get
this right, but a dh sequence always will)
- is there a missing dh_foo helper that would be advantageous to call, but
has not been called?
(e.g. if a future debhelper version adds a dh_sha256sums that should
be invoked before or after dh_md5sums, your packages won't benefit from
it automatically)
- is everything that this package does still necessary?
(e.g. as far as I can see, inn2 genuinely needs to be (fake)root so
it can chown things to root:news; kmod probably doesn't; but kmod is
calling dh_testroot, so it needs to be built under fakeroot anyway,
which makes the build more precarious by introducing an unnecessary
layer of LD_PRELOAD hacks)
Packages using dh also make it a lot more straightforward to do
archive-wide changes - similar to the benefit of using debhelper, but
for changes that affect the "shape" of the build system rather than the
details of individual steps. As a concrete example, in sufficiently
recent compat levels, dh ensures that you don't need the scaffolding
for making binary-arch, binary-indep, binary, build, etc. correctly
interdependent, which would have saved you some work when build-arch
and build-indep became mandatory targets, and more importantly would
have made sure these packages didn't block our progress towards being
able to make those targets mandatory.
Using debhelper build systems (dh_auto_whatever), instead of invoking
configure and make or their CMake/Meson/etc. equivalents yourself,
also has some important benefits for archive-wide changes. People who
are cross-compiling Debian have already gained a lot from this: they
can change how debhelper invokes (for example) Autotools or CMake,
in one place, and have it applied to all Autotools or CMake packages,
either immediately or the next time that package's maintainer bumps
compat level. As a result of this, the patches attached to a lot of
FTCBFS bug reports are of the form "stop calling configure, instead
call dh_auto_configure", which does the right thing without adding a
lot of open-coded logic to the package.
smcv
Reply to: