Hi! > > If I am successful, then lintian can specialize its efforts into issues only > > visible in packaged artifacts and thereby reduce it scope a bit. > > Perfect. I'd love to have some policy checking at "the right point in > time". I'd love to support this but as far as I understand even your > suggestion does not spare the work of fixing lintian itself. The problem > that motivated me to my initial mail to ask for help on lintian was about > packaged artifacts and we need to keep an eye on this - no matter how nifty > things we do before.
As somebody who has contributed to a bunch of Debian packaging tooling (Lintian, Deputy, git-buildpackage, Salsa-CI) I think Niels' approach makes a lot of sense. Deputy is great for static analysis of Debian packaging (i.e. are the files in debian/* syntactically and semantically correct). Lintian could over time remove those checks and focus only on analysing the build artifacts (as anyway Lintian can be run only _after_ the build was done). Yes, Lintian needs to continue to be maintained, but the maintenance work could be slightly less if Lintian adopts the strategy/architecture of focusing only on post-build artifact analysis. Regarding this discussion in general, I get the sense that participants haven't actually tried Debputy and are not aware of its capabilities. If you have Podman/Docker you can effortlessly run this little check to get some experience: cd my-package podman run --interactive --tty --rm --volume=$PWD:/tmp/my-package --workdir=/tmp/my-package debian:sid bash apt update && apt install -y dh-debputy python3-lsprotocol debputy lint Examples of output: pedantic: File: ./debian/changelog:944:82:944:89: Line exceeds 82 characters 944: - runtime-test-file-uses-supported-python-versions-without-python-all-build-depends informational: File: ./debian/control:64:19:64:24: Latest Standards-Version is 4.7.0 64: Standards-Version: 4.6.2