hi lintian and piuparts folks! relatively new maintainer of adequate(1) here.
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. source-package checks clearly belong in lintian. binary-package checks are trickier: - lintian is great to check requirements around mechanics (e.g. that a certain helper is used appropriately, rather than using ad-hoc code) - adequate is great to check system-wide invariants (e.g. program name collisions) but there's only so many of those - 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? browsing through lintian bugs, I've noticed some overlap with adequate: 1. #658210 lintian: Check that update-alternatives --install/--remove are always used in pairs overlaps with: #909342 adequate: warn about broken alternatives where should this check be implemented? a lintian check would focus on mechanics of updating alternatives whereas adequate would focus on end-state of alternatives, so probably adequate would be a better home for this check? 2. #455740 lintian: Please use desktop-file-validate overlaps with: #854208 adequate: check that Exec/Icon references in .desktop files resolve to existing files I did check that desktop-file-validate doesn't actually check Exec/Icon refs, so the q here again is where to implement the check. I think either place would be fine, would be happy to implement in adequate given how much work the lintian team already has, but don't mind either way. 3. #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? overlap with piuparts: 4. 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. relevant piuparts bugs: #699059 divide dangling symlinks in meaningful problems and noise #615034 divide dangling symlinks in meaningful problems and noise (fwiw lintian tag package-contains-broken-symlink was removed in 2.5.41 in 2016) 5. 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) thanks, serafi p.s. please cc me on replies
signature.asc
Description: PGP signature
