Re: Lintian usertag for janitor-related tags?

["Chris Lamb" <lamby@debian.org>]

Hi Jelmer,

> overrides don't communicate their intent
[…]
> In theory, we should at least be able to do something cleverer for cases
> (4) and (2). One (labour-intense and very slow) way to do this would
> be to add an extra field with intent - but maybe there are other
> ways of inferring intent?

No strong ideas here but from an information theory point of view, I
don't believe we have any other option that to explicitly capture the
maintainer's intent.

I don't think this is realistic in the current way we parse overrides
without making them even uglier, and maybe it is time for an entirely
new override file format anyway. Indeed, we could solve a lot of the
problems with the current one at the same time, least of all their
poor usability.

I suspect there is a very loose connection to the "Forwarded:
not-needed" header for patches. In fact, an 822-style override file
with paragraphs would not only solve many problems and this one, we
(the Lintian maintainers) would likely receive better feedback instead
of "# lintian BUG".


> line numbers in tag info
[..]
> There is no consistent format for line numbers in lintian output -
> some tags seem to report them between parentheses "Field blah (line XY)",
> some say "Field blah at line XY", etc.

Yes, currently these are all "just" strings. I am almost certain we
have discussed my preferred solution to this somewhere actually: when
we emit a tag in the Lintian codebase, in addition to the string that
we currently display, we optionally emit the filename and line number
in a structured manner.

While the command line could continue to show the existing "flat"
string, the Janitor and others could parse this data in some optional
JSON file output mode (or similar). This would also, for example,
finally allow us to link lines on lintian.debian.org directly to
the line on sources.debian.org.

(I believe I previously thought we could emit arbitrary structured
metadata, not just the filename and line number, but I am cannot
recall why this would be an advantage right now.)


> release compatibility
[…]
> lintian-brush has a configuration option for the latest release it
> will try to stay compatible with. This currently lives in a
> lintian-brush specific configuration file (debian/lintian-brush.conf),
> but it seems like this is something that more tools in Debian (like
> lintian) care about. Would it make sense to be able to declare the
> latest supported version somewhere else?

Can you elaborate on how this works within the Janitor? If you see
that package is defined as wishing to remaining compatible with Debian
version X, then Lintian tags that can only work on X + 1 are silenced?

If so, I have reservation that the fiddly management of the
tag-specific version metadata might be too high, but happy to be
corrected.

> verification of fixes
[…]
> write a JSON file with the results somewhere (rather than just writing
> to standard out), so that it's possible to check that the number of
> lintian issues has indeed gone done.

Getcha. This somewhat overlaps with my comments above re. structured
output (I can see this being written to a file without being emitted
to the commandline), but I suspect a "lintian --output=somefile.log"
or similar would work before that arrives?


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-