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