On 05/07/26 2:45 pm, Niels Thykier wrote:
> Nilesh Patra:
>> 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.
Thank you very much for the review!
> 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.
I don't expect a package to be even building with conflicting compat levels
so IMO there is not much of a risk. But even if it does, there is a check
for `length $debhelper_level` everywhere and somewhere down in the code
there is `debhelper_level ||= 1;` so I think we should be fine here.
I've tried to more or less adapt the same logic that was present earlier,
just with `dh_assistant`.
>> 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.
OK, I will see if I can fit some time for this, but low prio for me as well.
>
>>>
>>> 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.
Makes sense.
>> I feel the manpage should also state that doing "export DH_COMPAT=..."
>> globally
>> is discouraged as this means maintaining compat at 2 places.
>
> Thanks for the feedback on that. I have added a line to that effect.
Thanks for fixing that and also the new debhelper release!
Best,
Nilesh
