Re: coordination between lintian/piuparts/adequate
"Serafeim (Serafi) Zanikolas" <sez@debian.org> writes:
> hi lintian and piuparts folks! relatively new maintainer of adequate(1) here.
No-one replied so i thought i'd have a go, but i have no role in any of
this, just a user who has also tried to understand these tools
> 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)
i'd think:
lintian is static analysis, it doesnt install the deb, just looks at
its contents vs policy
piuparts is mostly about upgrades and removals -- and interactions
with other debs
this leaves adequate as "things lintian cant do as it would need the
deb to be installed" but which dont relate to upgrades/removals
(perhaps adequate and the "i" bit of piuparts could be merged, but
maybe the difference is that adequate only looks at once package? and
not sure anyone maintains piuparts any more?)
> (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?
seems like classic lintian check: it's about what the deb ships vs what
policy says
> #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?
the bug seems more like a lintian thing: "is the maint script helper
written correctly" but the extra that adequate could add is: "after the
package is installed, are the alternative symlinks broken? did something
sensible happen by default". (and piuparts would check that purging
chooses something else and doesnt break things?)
> #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.
if the icons are in the package then a lintian check would be best, but
if the deb is allowed to reference icons shipped by other package then
it would be good for adequate to check that they are present (which is
mainly checking that the package depends/recommends the right things)?
> #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?
this seems more like it should be a lintian check, assuming it can be
done without the package installed?
> 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.
id say this should be in several places, in different variants:
adequate, if the symlink target is allowed to come from another packahe
piuparts should be checking whether things are still Ok after upgrade/purge
(lintian, if there are any classes of symlinks where the target should
always be in the same source - which may never be the case?)
> 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)
i think this should mostly be lintian/piuparts but depends what is being
tested. I would expect lintian to check syntax, and piuparts to check
whether upgrades delete the right things?
Reply to: