Package: build-essential
Version: 12.9
Severity: wishlist

Hi!
I think it's time to revisit inclusion of debhelper into build-essential.
The last times it was formally proposed were five-digit bug numbers, and
Debian has changed a lot since then -- 99.82% packages in bookworm use
debhelper in some form (61 exceptions out of 33401).

My real reason: currently, every time a buildd installs dependencies, it
needs to manually add debhelper+deps after cloning the chroot.  This does
take time:
    debootstrap --variant=buildd unstable x 
http://apt-rosy.angband.pl:3142/debian
    time chroot x apt-get install -y debhelper
  → 7.888s
  (on an 8-way btrfs raid0 of optane disks, w/o eatmydata)
Many years ago, a reason "why not" I heard was that we'd fail to find
missing build-depends on debhelper.  That's not a concern anymore: new
packages B-Dep on debhelper-compat instead, and old ones can be spotted
with a lintian check.  I've also filed #1021877 asking to disallow
debian/compat in levels 14+, thus making sure such missing dependencies
won't ever creep back in (b-essential would guarantee dh 13 in bullseye+).

Policy reason: in #64827 you punted the request to debian-policy, as
their definition is "packages needed to build a C/C++ hello-world".
These days, using dh is not only "best practice", I even had ftp-masters
REJECT a package of mine because of using dirty tricks intead of
debhelper.  Thus, we can say that it's required in practice.

Ie, debhelper is truly ubiquitous, unlike C/C++ in the perl-python-go-
rust-haskell-font-docs world.


Meow!

Reply via email to