[Piuparts-devel] coordination between lintian/piuparts/adequate

[Paul Wise]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/piuparts-devel/attachments/20241207/f7e14db7/attachment.sig>