Adam Borowski:
Package: debhelper
Version: 13.10
Severity: wishlist
Hi!
It would be nice if you banned old-style debian/compat in upcoming compat
levels, in favour of the debhelper-compat b-dependency.
This would remove any need to check for missing debhelper dependency, and
allow speeding up buildds by preinstalling debhelper. 99.9% of packages
(61 exceptions in bookworm) use debhelper, yet it currently needs to be
installed with apt+dpkg for every single build, which does take a while.
In theory, there's a lintian check for missing debhelper b-dep, but that's
an extra moving part. Plus, in the far future, when we drop compat 13,
it'd be less complexity for you.
Meow!
[...]
One concern I have with this proposal is how would one use a non-stable
compat level? The self-hosted debhelper is a primary consumer of this
but we also see other packages opt'ing in to experimenting with the
"latest and greatest".
If I do not add the provides, you cannot request that debhelper-compat
and if I add the provides (before it is stable), then the dependency
does not guarantee you get a stable compat level when it is finalized
(defeating the purpose of a stable compat level).
The only alternative I see is to now have two Provides per compat
level (one for the experimental version and one for the stable version).
This includes me now having to track experimental compat levels as
something to be removed (meaning more administrative work for me).
Thanks,
~Niels
