[Draft] Bits from the lintian maintainers
Hi
See attached document; comments welcome :)
~Niels
Topics:
- Vendor profiles
- Configuration file changes
- Changes to Lintian options
- Other improvements
- Known bugs and issues
- Help us help you
Vendor Profiles
===============
Starting with version 2.5.2, Lintian can now be asked to produce the
same results as it would have on an Ubuntu machine or on the
FTP-master server, when dak checks packages for auto-rejects tags.
Using vendor profiles, it is now possible for vendors to choose any
subset of Lintian tags that matches their needs. Furthermore these
profiles can be used to alter the severity of any given tag or even
declare them as "non-overridable".
By default, Lintian will query dpkg-vendor to determine the best
profile for the given vendor, so developers only need to explicitly
state the requested profile when they need a special profile.
The default Debian profile inherits the "non-overridable" tags from
the ftp-master auto-reject profile.
Note: As in the past with the -F option, the ftp-master auto-reject
profile contains the list of tags that were auto-rejects at the time
Lintian was released. Therefore, the profile may be out-dated and
you can find an update to date list at [1].
[1] http://ftp-master.debian.org/static/lintian.tags
Configuration file changes
==========================
Lintian since 2.5.1 supports reading some options in the configuration
file. With this, you no longer have to pass up to 3 options to get
Lintian to display all the tags you want.
Version 2.5.2 featured a very important bug fix to this new feature.
Namely, Lintian now ships proper documentation on the configuration
file, so you no longer have to guess how to add options. Please refer
to "man lintian" for more information.
Changes to Lintian options
==========================
The command-line options has seen a number of changes since the
2.5.0~rc1. The following options have been removed or has been
deprecated and will be removed soon:
--unpack-level (removed in 2.5.0~rc3)
In Lintian 2.3.1 unpack level 2 disappeared. Since then
"--unpack" and "--remove" has largely made --unpack-level
redundant. Unpack level 1 was finally completely removed
in 2.5.2.
--checksums (deprecated in 2.5.1)
Lintian will now always verify the checksums listed in
changes files.
--packages-file (deprecated in 2.5.2)
This option was used to tell Lintian was packages to process via a
file with a special syntax. It primary use was for the
lintian.debian.org setup. This has been replaced by
--packages-from-file with has a simplier syntax.
The following options has been added:
--no-cfg (added in 2.5.1)
This prevents Lintian from loading any configuration file.
The option completely overrules any attempts to request a
config file (e.g. --cfg or LINTIAN_CFG).
--profile (added in 2.5.2)
This allows you to choose which vendor profile should be
used. Please see the "Vendor profiles" section above or
refer to the Lintian User Manual for the full details of
vendor profiles.
--packages-from-file (added in 2.5.2)
This asks Lintian to read the files to process from a file
(or stdin by using "-"). Lintian will consider each line
in the input as the name of a file to process. This is a
lot more "find $query |"-friendly and has replaced the old
option --packages-file.
Other improvements
==================
These days Linian
* has a test coverage of over 75% for tags
687 of the 915 tags that Lintian can currently emit are now
covered in the new test-suite. This gives a tag coverage on
75.08% and if the legacy test-suite is included, the coverage
hits 815 tags or 89.07%.
* processes related packages together
Since 2.5.0~rc3 Lintian has grouped related packages and processed
them together. With this Lintian can now do things like check if a
manpage is in a direct dependency.
* supports architecture specific overrides
In some cases tags may only appear on certain architectures and
since files must be "byte-for-byte"-identical in "Multi-Arch:
same" packages, Lintian now has architecture specific overrides.
For now it only supports "simple" architectures in the overrides.
* has a smarter test suite
The 4 test suites covering tags now all supports templates and
imports a "clean" package skeleton. This has allowed a
considerable reduction in "copy/waste" in the tests and gives
better results.
Known bugs and issues
=====================
* Overrides for non-overridable tags are silently dropped.
If a package has an override for a tag that cannot be overriden
(with the given profile), the override is silently ignored. The
fix for this is scheduled for 2.5.3.
* Unknown fields in profiles are silently ignored.
If a profile contains an unknown field, Lintian will silently
ignore the field. This fix for this is scheduled for 2.5.3.
Help us help you
================
As always, more hands are more than welcome. Lintian is a great project
to work on, if you have an hour or so. But even if you are not ready to
do regular work on Lintian, you can help us speed up your requests.
* Include a test for your new check or tag (or for the false-positive)
We would very much like to keep our tag test coverage above 75%.
Even if you are not ready to write an actual test case, a live
package with the issue helps us to write the test case ourselves.
* Include a description and references for new tags
Writing good tag descriptions and finding references often takes
even longer than writing the check and a simple test for it.
* Consider writing a patch or pseudo code for the new tag
In some cases a "check if package installs file X in Y then tag"
accurately describes what you want. But in some cases people
want more complex things and most likely you have an idea of how
to find the issue.
If you are interested in helping out, here are some of the things that
you can do:
* Help us write a "decent shell parser"
A lot of the current shell checks involves some clever regular
expressions that catches "common" cases. Unfortunately they are
prone to false-positives for alternative methods and each new
check requires a new "clever regex".
If you are interested, you can help us fix #629247, which
currently blocks 10+ bugs as well as reduce the amount of shell
parsing code in checks/scripts.
* Help us fix the 150+ open bugs on the BTS
Keeping up with the stream of bugs requires a lot of time.
* Help us find false-positives
There are plenty of tags overriden on lintian.d.o and some of
them might be due to false-positives that Lintian should know
about.
* Write a tool/library for our data refreshers
Lintian uses a lot of static data files and some of them are
semi-automatically refreshed by various tools. Most of these use
meta-files from the mirror (often available in the apt cache).
* Help us write "lintian-harness"
There has been some interest in improving the code behind
lintian.d.o and make it a public frontend. Particularly, if you(r
derivate) would like to setup a lintian.$domain.$tld, this might
be of interest.
We got plenty of other tasks beyond these, so feel free to write to
<lintian-maint@debian.org> and we will find something you can work
on. :)
We are working on a "README for developers" to make it easier for
newcomers to get an overview of the code.
Reply to: