Have you ever looked at packaging and felt it is a long exercise in repeating yourself? If you have, you are certainly not alone. You can find examples of this on the Debian mailing lists (among other places). Such as when Russ Allbery pointed out that the debhelper compat level vs. the version in the debhelper build-dependency that is very often but not always the same.
Russ suggests two ways of solving the problem:
- The first proposal is to generate the build-dependency from the compat file. However, generating the control file is (as Russ puts it) “fraught with peril”. Probably because we do not have good or standardized tooling for it – creating such tooling and deploying it will take years. Not to mention that most contributors appear to be uncomfortable with handling the debian/control as a generated file.
- The alternative proposal from Russ is to assume that the major version of the build-dependency should mark the compat level (assuming no compat file exist). However, Russ again points out an issue here that solution might be “too magical”. Indeed, this solution have the problem that you implicitly change compat level as soon as you bump the versioned dependency beyond a major version of debhelper. But only if you do not have a compat file.
Looking at these two options, the concept behind second one is most likely to be deployable in the near future. However, the solution would need some tweaking and I have spend my time coming up with an alternative.
The third alternative:
My current alternative to Russ’s second proposal is to make debhelper provide multiple versions of “debhelper-compat” and have packages use a Build-Depends on “debhelper-compat (= X)”, where X denotes the desired compat level. The build-dependency will then replace the “debhelper (>= X~)” relation when the package does not require a specific version of debhelper (beyond what is required for the compat level).
On top of this, debhelper implements some safe-guards to ensure that it can reliably determine the compat level from the build-dependencies. Notably, there must be exactly one debhelper compat relation, it must be in the “Build-Depends” field and it must have a “strictly equal version” as version constraint. Furthermore, it must not have any Build-Profile or architecture restrictions and so on.
With all of this in place:
- We have no repetition when it is not required.
- debhelper can reliable auto-detect which debhelper-compat level you wanted. Otherwise, debhelper will ensure the build fails (or apt/aptitude, if you end up misspelling the package name or using an invalid version).
- Bumping the debhelper compat level is still explicit and separate from bumping the debhelper dependency when you need a feature or bug fix from a later version.
Testing the prototype:
If you want to test the prototype, you can do so in unstable and testing at the moment (caveat: it is an experimental feature and may change or disappear without notice). However, please note that lintian is completely unaware of this and will spew out several false-positives – including one nonfatal auto-reject, so you will have to apply at least one lintian override. Also note, I have only added “debhelper-compat” versions for non-deprecated compat levels. In other words, you will have to use compat 9 or later to test the feature.
You can use “mscgen/0.20-11” as an example for minimum the changes required. Admittedly, the example cheats and relies on “debhelper-compat (= 10)” implies a “debhelper (>= 11.1.5~alpha1)” as that is the first version with the provides for debhelper-compat. Going forward, if you need a feature from debhelper that appears in a later version than that, then you will need an explicit “debhelper (>= Y)” relation for that feature on top of the debhelper-compat relation.
Will you remove the support for debian/compat if this prototype works?
I have no immediate plans to remove the debian/compat file even if this prototype is successful.
Will you upload this to stretch-backports?
Yes, although I am waiting for a fix for #889567 to be uploaded to stretch-backports first.
Will this work for backports?
It worked fine on the buildds when I deployed it in experimental and I believe the build-dependency resolution process for experimental is similar (enough) to backports.
Will the third-party debhelper tools need changes to support this?
Probably no; most third-party debhelper tools do not seem to check the compat level directly. Even then, most tools use the “compat” sub from “Debian::Debhelper::Dh_Lib”, which handles all of this automatically.
That said, if you have a third-party tool that wishes or needs to check the debhelper compat level, please file a bug requesting a cross-language API for this and I will happy look at this.
Future work
I am considering to apply this concept to the dh sequence add-ons as well (i.e. the “dh $@ –with foo”). From my PoV, this is another case needing a DRY fix. Plus this would also present an opportune method for solving #836699 – though, the hard part for #836699 is actually taming the dh add-on API plus dh’s sequence handling to consistently only affect the “indep” part of the sequences.