Nilesh Patra:
Hi Niels,I missed to incorporate (some of) these parts of the original bug report and had a couple of questions.Please recognize `X-DH-Compat` as the canonicalize spelling of that field (currently it incorrectly triggers `cute-field`) and as an alternative to `debian/compat`.I've opened an MR for this (`cute-field`).
Hi, Thanks for reaching out and for fixing this. :)
Related, `debian/compat` be phased out starting with compat 14.If I do not specify compat level in d/control, and have d/compat specifying the compat level as 14, this seems to work fine. What exactly does "phased out" mean here? What changes does lintian need to make?
The desired state is that `debian/compat` works up to and including compat 13. Once you want to use compat 14, you must replace `debian/compat` with a different source (for now, `X-DH-Compat` - once compat 14 is stable, `debhelper-compat (= 14)`).
But as you noted that is not entirely what happens.Because the introduction of `X-DH-Compat` happened after a number of packages had migrated to compat 14, I made the decision to provide a grace period. I warned all packages that used compat 14 that I was replacing `debian/compat` and it would become an RC bug soon. But to avoid immediate breakage, this particular compat change only takes effect once `debhelper` becomes version 14 (or later). That is, the moment `debhelper-compat (= 14)` becomes stable, having `14` in `debian/compat` will break (all except one package have been fixed and the last package has a bug, so the clean up is a tracked and solved problem in my book).
In summary, the "official statement" is:
* `debhelper-compat (= X)` works for any stable compat level
* `X-DH-Compat: X` works for any supported or experimental compat level
* `debian/compat` work with any supported or experimental compat 13 and
below.
You noticed the "fine print" for the last bullet point here (where it
temporarily allows 14 until I hit the big red release button). I
recommend you ignore that "fine print" and stick to the "official
statement".
Note `debhelper` manages this with hard errors when its rules on the compat front is violated, so there is no reason for `lintian` to add tags for people using compat `14` in `debian/compat`. A nice-to-have could be to pedantic level nudge people away from `debian/compat` (towards either `X-DH-Compat` or `debhelper-compat (= X)`). But I think most people have already jumped on the `debhelper-compat (= X)` boat long ago, so it is probably not worth it (if that nudge does not already exist).
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`).
Is there an option to get the value directly instead of json? (saves lintian some parsing)
No. Though, last I checked `lintian` would also need the `declared-compat-level-source` field that describes the "source" of the compat level anyway. I forgot what for, but it used to be a piece of information relevant to either a tag or decision somewhere.
Please let me know. Best, Nilesh
Hope the above answered it and thanks for working on this. :) Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
