Hi Chris, On Fri, Sep 11, 2020 at 08:13:02AM -0000, Chris Lamb wrote: > > 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". A new format for the overrides file that is easier to understand and more extensible (allowing e.g. field that indicates the reason for the override) would make a lot of sense, I think. > > 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. I haven't looked at the numbers for lintian, but the tags that the janitor fixes aren't generally version-constrained. E.g. if the VCS URL is not canonical, that's something that can be backported to any Debian release. Most of the fixers that are constrained specify what debhelper version they require, and the janitor then compares that debhelper version against the known debhelper in the user-specified minimum supported Debian version. It seems like a perhaps a good next step here would be to do the analysis and figure out which of the ~1400 lintian tags would require tag-specific metadata, so you have some idea of what the impact would be. > > 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? Yeah, some way to write the output in a structured manner to a separate file in addition to the regular output to stdout in particular would be great. Cheers, Jelmer
Attachment:
signature.asc
Description: PGP signature