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

[Serafeim (Serafi) Zanikolas]

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
-------------- 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/20241027/b4ac68d8/attachment.sig>