The new version of Lintian (2.5.8) can pretty much be summed up as:
Its like 2.5.7, only with less false positives and no FTBFS.
Especially people annoyed by the hardening flags will hopefully find that 2.5.8 greatly reduces the number of false positives. I believe this is best demonstrated with an example:
$ lintian --print-version && lintian -q -C binaries amarok_2.5.0-1_i386.deb | wc -l 2.5.7 94 [...] $ lintian --print-version && lintian -q -C binaries amarok_2.5.0-1_i386.deb | wc -l 2.5.8 4
However, nothing comes for free. We dropped hardening-no-stackprotector from the default profile (and demoted it to an “I” tag). For hardening-no-fortify-functions we made a “false positive -> false negative” trade-off by ignoring binaries if their only unprotected function is memcpy. For more information, please refer to #673112.
hardening-no-stackprotector is still available and can be used via the debian/extra-hardening profile (or via the –tags argument). For the 2.5.7 behaviour of hardening-no-fortify-functions, you have to use hardening-check directly.
But 2.5.7 had other changes besides the myriad of false-positives:
- Around 19 redundant tags were removed.
A consequence of this is that we no longer warn if you use things like “dpkg –assert-working-epoch” or your postinst creates a “usr/doc transition symlink”.
- The last of the Lintian’s (perl) modules have been put under the Lintian name space.
With all the Lintian modules under the Lintian namespace, we can install them in the standard perl @INC path. Admittedly, I am not certain we are ready to commit to the current API in these modules, which is one of the reasons why they are still installed in /usr/share/lintian. But in a couple of releases things may look differently.
- Lazy loading of data files
Lintain 2.5.7 ships over 50 data files of various kinds (usually white- or blacklists of some kind). Before 2.5.7, all data files with a few exceptions would be loaded eagerly (i.e. as soon as the check was run for the first time). A few data files had been special cased with “manual laziness”.
In 2.5.7, Lintian::Data was updated to lazily load the data. So depending on the packages being checked, Lintian may now load fewer data files.
- Create proper data files for tables embedded within checks.
While this is not something exclusive to 2.5.7, we have separated quite a few checks from their data tables by now. My personal favorites are the table of known interpreters and (from 2.5.8) the table of known versioned interpreters.
- Support for Vendor specific data files.
I am certainly biased here. But this is probably the most awesome feature in Lintian 2.5.7. It is now possible for vendors to extend or simply “shadow” the core Lintian data files. Allow me to demonstrate how this can be used:
$ lintian --tags build-depends-on-obsolete-package a2ps_4.14-1.1.dsc E: a2ps source: build-depends-on-obsolete-package build-depends: dpatch $ cat ~/.lintian/profiles/local/main.profile Profile: local/main Extends: debian/main $ cat ~/.lintian/vendors/local/main/data/fields/obsolete-packages @include-parent @delete dpatch bison $ lintian --profile local/main --tags build-depends-on-obsolete-package a2ps_4.14-1.1.dsc E: a2ps source: build-depends-on-obsolete-package build-depends: bison $
It is a toy example, but I believe it is a good demonstration of the feature.
The full documentation of Vendor specific data files can be found in the Lintian User manual (in lintian/2.5.7 or newer). It will also be on lintian.debian.org when we find time to update lintian there.