Control: tags -1 wontfix
Andreas Tille:
Package: debhelper
Version: 13.16
Severity: wishlist
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
[...]
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
