The dpkg-dev toolset has many defaults, many of which have not aged well. Changing these defaults to better alternatives is in many cases impractical, as that requires at least a distribution-wide transition, and that might still break many external source packages.
One solution to this problem would be to adopt the compatibility level concept that debhelper has been using for many years now, which has allowed it to push forward newer and improved defaults progressively, at the maintainer discretion. The usage of the new versioned Provides, means we would not need to introduce any new file, and would make checking for this value easier from the Sources indices.
We need to clarify (in case it is not already clear) how the new defaults can be reverted or overridden, so that people can use a new compat level but opt-out of some specific items.
There's a WIP branch at https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/perl-Dpkg-BuildAPI.
We'd make dpkg-dev Provide a new virtual package, for example dpkg-toolset-compat (= 0) or dpkg-build-api (= 0).
Compatibility level candidates
- Supported debian/rules targets.
- Default R³ value.
- Default build flags.
Default generated build paths (debian/<build-path>).
Compat level 0
Either an explicit level or its omission would imply the current values.
Compat level 1
- Require all non-optional debian/rules targets.
- R³ default to no.
- Add bindnow to default build flags.
Change default build paths (debian/<build-path>) to the namespaced proposal (needs ref here).
- Modify behavior of make fragment files:
- Switch default for dpkg_vendor_derives_from.
- Include buildtools.mk in defaults.mk.