Hi! Some time ago I started work on a new dpkg build API level system resembling the one used by debhelper. My current WIP is at <https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=pu/perl-Dpkg-BuildAPI>, which I'd like to finalize and merge for 1.22.x.
This works by making packages build-depend on «dpkg-build-api (= N)» (which dpkg-dev then provides), or by setting the environment variable DPKG_BUILD_API=N (which overrides the value in the file, but might emit a warning if it's different). This will control what the dpkg build API is for that package. There is also a make fragment file (buildapi.mk), and a companion tool to extract the build API level called dpkg-buildapi(1) to be used from scripts or similar. The main reason behind the environment variable is to avoid having to re-parse the control file all over the place, or possibly for testing purposes (local or global). Unfortunately I don't see a way (that does not involve layer violations) to delegate driving the level to a helper like debhelper (which could then automatically set specific dpkg-build-api levels from its own levels) because this needs to be set before something like debhelper is even in the picture, but it could still tie them by making them a requirement and otherwise failing, so it could get some baseline guarantees. This should make it possible to change current defaults that we could not otherwise change. The idea would be that level 0 would keep the current semantics, where behavior might be changed after specific global transitions, or the usual deprecation cycles or similar, but for N >= 1, the behavior will be set in stone once defined and can only be changed by adding a new level. The current list of behavior change candidates for N=1 includes: * dpkg-shlibdeps no longer uses the LD_LIBRARY_PATH environment variable. * dpkg-buildpackage defaults to Rules-Requires-Root to no. * dpkg-buildpackage requires all required debian/rules targets. * vendor.mk defaults to using dpkg_vendor_derives_from_v1 for the dpkg_vendor_derives_from macro. * default.mk defaults to including buildtools.mk. * dpkg-buildflags changes default build flags (TBD). And that last one I'm still working my way through, but I'll send a separate mail for that one. So I'm interested in feedback on whether people see any issue with the above, and in particular Niels input (although I've already floated this to him in the past) on whether this plays nicely with debhelper, or whether there is something specific that could be improved or changed or similar for its usage, or further proposals for behavior changes. Thanks, Guillem