Nilesh Patra:
Hi Niels,Thanks for a detailed answer.
You are welcome. :)
On 05/07/26 12:58 pm, Niels Thykier wrote:[...]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.
Ok. I do not have a strong argument either way and it feels squarely as something that is within your call to make as the one writing the code.
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.
Thanks, commented a few minor things I noted.I did not check how the proposed code handled conflicting "base compat" levels. The `dh_assistant` call will fail and that will result no compat level in the code. I think logic-wise, it is fine, but it might be confusing. But then, it is hard to build such a package now, so I just wanted to confirm it was an "accepted risk"/intentional part.
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.
The tag itself is based on probability and explicitly state it should be overridden when there are exceptions, so I see no issue with the override.
As per earlier mails, we discussed if dh_assistant could be moved to libdebhelper-perl - would that be possible?
It would be, but it is not super high on my list on account of being complex/annoying to do compared to the things that I know it unblocks/improves. Especially since I cannot use `dh-exec` (breaks self-hosting) and I do not want to split globs into subglobs in `install` and `manpages` files (risk of missing new commands). It will probably end up being some `rm -f` in `debian/rules`
I am also open to taking a patch.
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 think it was correct in assigning higher priority between DH_COMPAT and the others under the previous semantics. Additionally, in case of a conflict between the options for the "base compat", I also feel it was fine for lintian to select one of them and give that priority for simplifying other code paths (to avoid having a level of compat levels in subsequent checks).
Obviously, none of that is relevant with the changes that you are proposing and that is also fine take to have.
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
Thanks for the feedback on that. I have added a line to that effect. Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
