Hi Niels,

as some (extremely late) follow up to our discussion[1] about lintian
and the fact that its checking binary artefacts at a way to late stage
I'd like to propose some solution of checking policy issues early.

I could perfectly imagine to have some first "lintian-like" step after
dh_clean, checking for instance spelling errors in debian/* or issues
in d/copyright.

I could similarly imagine some dh_* plugin after dh_install to check
several things as well that do not require a readily built package.

Kind regards and thanks for all your work on debhelper
    Andreas.


[1] https://lists.debian.org/debian-devel/2024/05/msg00162.html

Andreas Tille:
Hi,

Thanks for filing this feature request against debhelper.

Unfortunately, this feature is not a great fit for debhelper and I do
not see it being a part of debhelper. The most obvious reasons being:

  1. Given `debhelper`'s design, a `dh_X` command should be fairly
     trivial. A policy checker is historically anything but "fairly
     trivial" and would quickly (if not immediately) exceed `debhelper`'s
     complexity requirements. Therefore, for `debhelper` to provide this
     feature `debhelper` would have to delegate this functionality to a
     third-party tool that does the heavy lifting. Accordingly, the
     policy checker would have to be exist and be provided by a third-
     party package rather than being built inside `debhelper`.

  2. Any critical build framework needs absolute minimal dependencies as
     any dependency becomes part of the bootstrap. Accordingly, re-using
     existing helpers such as `lintian` and `debputy lint` is out of the
     question. Even in `debputy`, which has a "built-in" `lint` command,
     the `lint` subcommand as a deliberate choice relies on optional
     dependencies specifically to avoid tainting the minimum
     requirements for `debputy` (as a package helper) itself.

     - Note a third-party debhelper plugin is not equally constrained
       and could provide this feature (outside `debhelper`) for packages
       that opt-in. Though this just pushes the complexity on to the
       consumers, which I am not a fan of either. Especially considering
       that is hard for people to tell if/when their package becomes a
       part of the critical bootstrap set. Nevertheless, you or anyone
       else is welcome to do such a thing if you believe it to scratch
       your itch.

These two combined implies that for `debhelper` to supply this
functionality, someone would have to build an entire set of checks from
scratches with a commitment to minimal/zero dependencies (which neither
`lintian` nor `debputy lint` tries nor wants to do). This does not seem
like a good investment of my time nor my energy, so I am not going to
volunteer.

Though, if it scratches your (anyone's) itch, feel free to go ahead and
prototype it via third-party `debhelper` add-on. If said add-on becomes
a success, `debhelper` can always Depends on it like it does with a few
other key tools like `dh-autoreconf` or even absorb the `dh_X` command
wrapping the tool (but not the tool itself).

Best regards,
Niels