Nilesh Patra:
Hi Niels,I'm reviving a part of the old discussion...
Hi,
On 01/05/26 10:08 pm, Niels Thykier wrote:Nilesh Patra:Hi Niels,Note: `lintian` can use `dh_assistant` to determine the compat level instead of implementing the logic itself for checking various fields and files (the `export DH_COMPAT` checks for `debian/rules` might still be necessary). Though, this implies debhelper/13.15+ as a dependency for it to recognize `X-DH-Compat`.What is the better field to use to detect compat level? Is it `declared-compat-level` or `active-compat-level`?For `lintian`'s case, you probably want `declared-compat-level`. That is the compat version "declared" directly in the packaging files/metadata. The `active-compat-level` is the compat level used if you execute a command in the current environment (that is, it takes things like the `DH_COMPAT` environment variable into account. But that is unlikely to be set nor mean anything for `lintian`).Currently dh_assistant ignores `DH_COMPAT` set in d/rules, as far as local experiments show. Lintian at the moment has "debhelper-compat > DH_COMPAT in d/rules > d/compat" precedence for setting compat as per [1][2][3]. However I think this should be discouraged, and dh_assistant does not take this into account either. So, I think we should take compat from debhelper-compat and d/compat only and use DH_COMPAT as a fallback to emit the compat level. I've done so in this MR [4]. Does this make sense - or should DH_COMPAT always come at a higher priority? Additionally could you take a look at the MR and let me know if this is making sense with compat level selections? [...] Best, Nilesh
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`.
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.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
