Re: coordination between lintian/piuparts/adequate
Paul Wise <[email protected]>
| Newsgroups | gmane.linux.debian.devel.quality-assurance,gmane.linux.debian.devel.lint.devel |
|---|---|
| Organization | Debian |
| Message-ID | <[email protected]> |
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
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmdTy9oACgkQMRa6Xp/6 aaOxGw//dp0GguPZ5mLIfwAK07rWtY3bGdgntuT2ECj6iHkQKNY1nW6UNZGjg5xY n0mepPiBPYiE/UBOKzVSbMeCdoZoVIAODzi3/HWLWxhPHdm4Spfr+SvacZQU29/V ysd8SYy0w/7o+pT6hz7IE8vIdZrP5at/eatQTy7oZ/NxHn57X9TKwMy8lDoU/Glg KjVloqfh9XIjByJWCx9DimxGAv04ZBID9/kKM2UFoCIvnnsp6SNJ9Qj++FGk05FN A2gA849RNGzUSKxb3CIWKxIDNnH2zsejd7GKX6bbEjrNY1bZOugnQY3hq3/xZq/U pg4qfyEdTV9zKW2F4f73LOXn3WKbL3I4UriIjfRRfopyO2jyOT8EVzfAqW2Z/W6j O3HXtrhnXXbeIzZxP0U+dX0+h62w69cEqBLbN2jNLfnlqxggtr8bJYbSUVschYtg kUzDp76A6u4hG/yNvOrv1PVTbNsEZAF6xtlCfUhK+2z9pwhrft3UViimG74i8M2S mmBy0WOCZM2Fq27zKVq3h2ikkKvh8iA3/Eq/+s3cHSEYiVmg4Py5rKhlPXR+YYhX 8GUJwOBs8R9QOwthNiWQ2D+JyH2bc+9aNp3PQQWsxOq5dSo9ZlU8kSaOO3b7kZBo 7w4Z/JN6JOhJjIai4lTundNXxd6L48TAlbePC0VxSrQl9R5Ohx4= =Y3K/ -----END PGP SIGNATURE-----