Hi Niels, Thanks for a detailed answer.
On 05/07/26 12:58 pm, Niels Thykier wrote: > I have not read the PRs, but this textual description makes me feel like > there is a misunderstanding of how the compat levels declarations > interact and should be used. > > There are 4 ways to set the compat level, which I will group in to two > precedence groups: > > 1. `debhelper-compat` build-dependency vs. `X-DH-Compat` in d/control > vs. `debian/compat`: > > These three all declare the source package "base compat" level. Each > source must use **exactly** one of set the "base compat" level. When > there is not exactly one of these, then debhelper will abort with > an error message. > > Note here: `debian/compat` is now being phased out, so eventually > there will only be two options in this category. > > 2. The `DH_COMPAT` environment variable: > > The `DH_COMPAT` environment variable can be used to override the > "base compat" level to a different level. This is usually done > per command or rules target. Like: > > > The entire package uses compat level 13 except the command > > dh_gencontrol, which uses compat level 14. > > I believe this was historically the **only** way to declare compat > levels prior the first option of method 1). This could explain why > there are signs left of a top level `export DH_COMPAT = ...` in > `lintian` and source packages. However, setting it global just like > this today just means you have to places to maintain the compat > level. > > Note here: Just setting `DH_COMPAT` without any option from 1) will > still fail. The `debhelper` commands assume that `DH_COMPAT` will be > unset for some other command about to be called later (or before), > so there must always be a "base compat" level. > > > This is also why `dh_assistant` ignores `DH_COMPAT` in `debian/rules`. > It is trying to answer, what compat level should we currently be > running. For lintian, it can answer "what is the base compat level" > (that is, point 1). But as you concluded, it is not useful for telling > whether there will be override from some command via `debian/rules`. I think lintian should check for only base compat level, and flag violations with DH_COMPAT where necessary. In particular tags like declares-possibly-conflicting-debhelper-compat-versions debian-rules-sets-DH_COMPAT And not actually use that variable to decide what compat level the package is running at. The code until now was actually using this variable to decide compat level (in Debhelper.pm) which may have been for historical reasons. Since dh does assume that the DH_COMPAT will be unset at some point, lintian should consider the same. So in the MR, I am taking up the base compat level which `dh_assistant` gives me and use that as the actual compat everywhere. (There are other checks apart from Debhelper.pm that rely on it and hence I moved some stuff directly into processable). If you could take a look at the MR once, that would be very helpful for me. Also, while we are at it, lintian now has a Depends on debhelper which triggers "binary-package-depends-on-toolchain-package Depends: debhelper" and I have overridden this for now. As per earlier mails, we discussed if dh_assistant could be moved to libdebhelper-perl - would that be possible? > > This is the same point that I am trying to get across in > `man:debhelper.7`, section COMPATIBILITY LEVELS. The term "base compat" > is just the compatibility level, and `DH_COMPAT` is referred to as a way > to temporarily override the compat level. I hope you will give at a read > as well and comment on places where it could be improved to avoid this > kind of misunderstandings for others. It should be the same as above > with a bit less historical information. I took a look. While the manpage is clear, the existing code in lintian caused some confusion for me, as it would set compat levels on basis of some priority. I feel the manpage should also state that doing "export DH_COMPAT=..." globally is discouraged as this means maintaining compat at 2 places. Best, Nilesh
