Lintian 2.5.44 was released the other day and (to most) the most significant bug fix was probably that Lintian learned about Policy 3.9.8. I would like to thank Axel Beckert for doing that. Notably it also made me update the test suite so to make future policy releases less painful.
For others, it might be the fact that Lintian now accepts (valid) versioned provides (which seemed prudent now that Britney accepts them as well
). Newcomers might appreciate that we are giving a much more sensible warning
when they have extra spaces in their changelog “sign off” line (rather than pretending it is an improper NMU). But I digress…
What I am here to talk about is that Lintian 2.5.44 started classifying packages based on various “facts” or “properties”, we can determine. Therefore:
Every package will have at least one
- These labels are known as something called “classification tags”.
The tags are not
issues to be fixed! (I will repeat this later to ensure you get this point!)
Here are some of the “labelled boxes” your packages will be put into:
- Source packages will unconditionally have both:
- Binary packages will have one of:
The tags themselves are (as mentioned) mere classifications and their primary purpose is to classify or measure certain properties. With them any body can download the data set and come with some bold statement about Debian packages (hopefully without relying too much on “ lies, damned lies and statistics
“). Lets try that immediately!
Almost 75% of all Debian packages do not
need to run arbitrary code doing installation!
- The “dh-sequencer” with cdbs is the future!
In the next release, we will also add tracking of auto-generated snippets from dh_*-tools. Currently unversioned, but I hope to add versioning to that so we can find and rebuild packages that have been built with buggy autoscripts (like # 788098
If you want to see the classification tags for your package, please run lintian with like this:
# Add classification tags $ lintian -L +classification # Or if you want only classification tags$ lintian -L =classification
Please keep in mind that classification tags (“C”) are not issues
in themselves. Lintian is simply attempting to add a visible indicator about a given “fact” or “property” in the package – nothing more, nothing less.
Future work – help (read: patches) welcome:
- Do something better with classification tags on lintian.d.o (like stacked graphs)
- Classify more (useful) things.
Optimising the memory usage of the reporting framework
now that we permanently increased the number of tags.
- Your idea (with patches) here …
 Mind you, the reporting framework’s handling of these tags could certainly be improved.
 Please note how it distinguishes 1.0 into native and non-native based on whether the package. Presumably that can be exploited somehow …
 Disclaimer: At the time of writing, only ~80% of the archive have been processed. This is computed as: NS / (NS + WS), where NS and WS are the number of unique packages with the tags “no-ctrl-scripts” and “ctrl-script” respectively.
 … or maybe not, but we got two packages classified as using both CDBS and
the dh-sequencer. I have not looked at it in detail. For the curious: libmecab-java and ctioga2.