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

[Serafeim (Serafi) Zanikolas]

hi Paul, thanks for the feedback. please see comments inline

On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:
> 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.

I completely agree. the problem is that "can be done statically" is rather
vague. that's why I made the distinction between "user visible effects" (e.g.
dpkg-query reports orphaned conffile) vs "correctness/adequacy of employed
package building mechanics" (e.g. certain helpers are called from certain maint
scripts).

> > - 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.

I'm not suggesting to drop already implemented checks in lintian, but given the
lintian maintainer workload, I'd expect lintian maintainers to prioritise
implementing can-only-by-done-by-lintian checks, over could-be-done-by-either
lintian/adequate checks.

> > #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.

imho that's reason to drive adequate adoption (e.g. with autodep8 and salsa ci
pipeline) and make piuparts.d.o feed adequate results to tracker.d.o, rather
than expect lintian maintainers to implement checks that are easier to do so (or
already exist) in adequate)

> > [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.

ack.

> > 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.

that's because unsupported ports architectures have not caught up to go 1.21,
which was released ~1.5 year ago. I'd claim that that says more about the
viability of those ports, than the suitability of go for Debian tooling. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider
audience at <D4CWM2UJBXDS.339WS39VNMVYO at debian.org> rather than reply here

> 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.

piuparts relies on humans to file bugs. autopkgtest on the other hand blocks
package migration to testing (that is, when one does not run autopkgtst before
upload). it's nice that some humans (including yourself) file bugs, but that
doesn't seem viable long-term. also note, that I'm very keen to keep adequate
free of false positive failures, so that people do feel comfortable running it
with autopkgtest (and even then, one can selectively disable tags)

> > 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.

ack.

thanks,
serafi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/piuparts-devel/attachments/20241210/add558d2/attachment.sig>