On Sun, 2024-10-27 at 00:43 +0200, Serafeim (Serafi) Zanikolas wrote: > it seems to me that it'd be useful to write down some criteria to use as > guidance on how to decide where new checks should be implemented, to avoid > duplication.
Checks that can only happen after install such as cross-package checks should go to adequate and checks that can be done statically for a single binary package or all binary packages from the same source should go to lintian. > - checks hermetic to the installed state of a package (e.g. #1071061 "lintian: > Should warn if a package ships /usr/lib/python*/dist-packages/__init__.py") > could live in either of lintian/adequate; I can't think of strong reasons > either way; what do you think? A check in lintian seems appropriate. The more general problem of detecting whole-archive file conflicts cannot be done in piuparts or adequate, you need something like dumat or dedup.d.n for that. Even that isn't going to detect conflicts created after install. > #658210 lintian: Check that update-alternatives --install/--remove are always > used in pairs > overlaps with: > #909342 adequate: warn about broken alternatives I would suggest both lintian and adequate, since lintian does not have a shell script parser for interpreting maintainer scripts and even if it did probably couldn't detect all situations that result in broken alternatives, and can't detect breakage on a system caused by a package from a third-party, the sysadmin or a rogue malicious program or user. > #455740 lintian: Please use desktop-file-validate > overlaps with: > #854208 adequate: check that Exec/Icon references in .desktop files resolve > to existing files Both should be implemented. Adequate since Exec/Icon references are potentially cross-package, but aren't always. > #524357 lintian: Ensure that packages providing x-window-manager register the > alternative > this check is already implemented by adequate (also for x-terminal-emulator), > so > #524357 can just be closed? IIRC piuparts.d.o doesn't expose adequate results to tracker.d.o, while lintian does, and lots of people run lintian locally but not piuparts or adequate. So the audience for lintian is much higher than the audience for adequate. So having this in lintian would be useful too. > [adequate] overlap with piuparts: adequate can be used in more locations than just in piuparts, so please keep that mind when deciding on where to add checks and deciding to remove checks entirely. > adequate has a broken-symlink tag, but piuparts detects broken symlinks on its > own so disables broken-symlink checks on adequate invocations. should adequate > remove broken-symlink, or piuparts drop its implementation of broken-symlink > in > favor of adequate's? arguably, there's some value in adequate keeping the > functionality so that one could catch issues early, by running adequate as an > autopkgtest. Probably adequate is the logical place for this test, but adequate doesn't build/run on ports architectures since it moved to golang, so piuparts should probably keep its tests on those arches until adequate moves to a more portable language or golang gets ported. Since piuparts already runs adequate under all the package scenarios that autopkgtest runs tests for, there is no need for autopkgtest to run adequate. If anything, piuparts should run autopkgtests after it installs the packages and runs adequate. The current situation with autopkgtest seems like a bunch of layering violations to me. > ditto for adequate obsolete-conffile -- piuparts disables it in favor of its > own > logic. it'd seem to me that the logic should stay in piuparts, given that > install/uninstall/upgrade is core to what piuparts tests. so there's a case > for > adequate's obsolete-conffile to, if not to be dropped, to at least not run by > default (since, e.g. it's useless in an autopkgtest context) Several folks use this specific test on our systems (outside piuparts) for filing bug reports about obsolete conffiles, so please retain it. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
