[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Lintian maintainers

Hash: SHA256

  - 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 Lintian

  * 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 built from the same source

  * 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,
    not wildcards like "linux-any".

  * 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

  * 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
    derivative) 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.  You can find it as
doc/README.developers in the git repository.

Version: GnuPG v1.4.11 (GNU/Linux)


Reply to: