On 02/05/26 1:03 pm, Niels Thykier wrote:
> The entirety of `debhelper` is built around global state and the code
> has filled with weird warnings and hard errors that will be emitted in
> various special-cases.
>
> I am not convinced the `libdebhelper-perl` is capable of properly
> cleaning its global state well enough to reliably work with `lintian`'s
> use cases (such as processing multiple packages in one invocation).
>
> If you want to do this, you have to use process isolation (`fork`),
> `chdir` into the unpacked source root, and then invoke
> `Debian::Debhelper::Dh_Lib::get_compat_info`.
>
> It will save you the dependency, but not much else from a complexity
> PoV. It might be better to move `dh_assisant` to `libdebhelper-perl`.
I took a look at the code for both `dh_assistant` and current handling
in `lintian`.
There are some cases where `dh_assistant` would give a json, and `lintian`
can parse that.
However, for some edge cases where there are packaging issues, `dh_assistant`
errors out with for instance:
| dh_assistant: error: debhelper compat level specified both in debian/compat
and in debian/control
| dh_assistant: error: Sorry, debian/compat is no longer a supported source for
the debhelper compat level. Please add a Build-Depends on `debhelper-compat (=
C)` or add `X-DH-Compat: C` to the source stanza of d/control and remove
debian/compat.
Which makes sense.
But, that would mean `lintian` would need to add in additional parsing logic to
process these cases
and change the current logic to flag these things.
There would probably be more error cases which I did not explore. This means
writing a wrapper on top
of existing `dh_assistant` to process `dh_assistant` errors.
I feel this is a bit too cumbersome at the moment. It would probably be
significantly easier to switch to
`dh_assistant` when `debian/compat` is fully phased out and no package uses it.
We can re-visit this then
and think about using `dh_assistant` then.
Let me know your thoughts.
Best,
Nilesh
