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

[Serafeim (Serafi) Zanikolas]

hi,

> On 2024-10-27 7 h 16 p.m., Richard Lewis wrote:
> > "Serafeim (Serafi) Zanikolas" <sez at debian.org> writes:
> > 
> >> 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)
> > 
> > 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

adequate can be invoked for any number of specified packages including all of
the locally installed ones. and unlike lintian, it's pretty fast (<10s in my
very aging laptop for all packages) but that's not a fair comparison because
lintian implements 100x more checks than adequate.

> >    (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?)

piuparts invokes adequate for one package at a time (because that's how piuparts
operates); "adequate --all" analyses all installed packages. piuparts is
actively maintained (69 commits as of now, in 2024).


On Tue Oct 29, 2024 at 4:32 PM CET, Louis-Philippe Véronneau wrote:
> Hi,
>
> Thanks for reaching out.

thank you for getting back to me. it really feels like we should talk more :)

>
> I can't really speak for piuparts, but I agree with what Serafeim wrote 
> for the lintian part.

I take it that you'd then be okay for me to close/merge/reassign the
aforementioned lintian bugs.

> One of the strengths of lintian and piuparts is a lot of people run them 
> each time they build a package. Adequate needing the package to be 
> installed makes it harder to integrate in that workflow.

piuparts Recommends: and (if the Recommends: is honored) runs adequate so it
seems contradictory to me to claim that piuparts is widely used and adequate is
not. my impression is that neither piuparts nor adequate are widely used
locally (the piuparts folks do run piuparts.debian.org, which is cool but has a
much longer feedback loop than running the tools before upload). popcon has
higher numbers for adequate, but that might be skewed by its apt hook (disabled,
by default)

> Maybe if it was a feature in sbuild it would help?

no need to. adequate needing the package to be installed makes it a perfect
candidate for autopkgtest; /usr/share/doc/adequate/README has one-liners on
how to use autopkgtest to run adequate on all of a source package's binary
packages. however, only ~15 source packages currently use adequate with
autopkgtest

I think that there's a lack of awareness of adequate among maintainers, for good
reason:

- adequate is much younger than lintian, and has been orphaned for most of its
  lifetime
- maint-guide has no mention of it (the devref on the other hand does)
- devscripts recommends lintian but only suggests adequate

I'd like to think that wider adoption of adequate is do-able, but first I want
to convince myself that it's worth it, by:

- first bringing clarity to what should be the boundary of features between
  lintian and adequate,
- ensuring that that boundary leaves enough of a problem space for adequate, to
  justify having to drive wider use of adequate with all the cost that that
  would entail in maintainer attention

anyway, I still need to think through the criteria for that boundary and this
email is already a bit too long.

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/20241101/6925c4b2/attachment.sig>