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

lintian -- detecting hundrets of bugs within seconds...



Hi folks!

Together with Richard Braakman I'm working on a policy checker tool called
`lintian' which is a collection of shell/perl/python scripts to check
Debian packages (binary and source packages) for compliance with latest
Debian policy.

There are three fields of applications for lintian:

  1) one person could use lintian to check the whole Debian archive and
reports bugs, keeps track of these bug reports, etc.

  2) each maintainer runs lintian over his/her packages before uploading
them 

  3) dinstall on master runs lintian over all newly uploaded packages and
rejects packages with severe errors (there will be an override mechanism
to bypass certain lintian scripts)

The most important differences to the other policy checkers (deblint,
dpkglint, etc.) are:

  - flexiblity: lintian is a collection of scripts which are divided into
several layers: unpacking, collecting information, checking, bug
reporting, bug watching

  - completeness: our goal is to write lintian checking scripts for
(nearly) everything that can be checked mechanically

  - uptodateness: lintian will be updated whenever policy is changed

  - performance: since the unpacking/collection process is seperated from
the checking process, it's possible to extract information about _all_
packages in the archive first (takes about 3 hours on my P120), and then
run several checks of the full archive (takes a few minutes only!)

  - ...

(Since I don't want to sell lintian for money I stop here ;-) 

In short: The design issues have been worked out in detail already and the
framework of scripts is finished. I've already coded two tests: copyright
policy and shared library policy (see below). More tests will be written
in the next days. 

When the code has stabilized, I'll upload a first package of lintian for
wider use. If someone is intrested in seeing a first version and coding
a few tests, please drop me a note and I'll send you my current version.

Ok, now to the checks: Each check script reports lines of the following
format:

   N: <verbose text for the user>
   W: <pkg>: <tag> <arguments>
   E: <pkg>: <tag> <arguments>

N stands for `Note', W stands for `Warning', and E stands for `Error'.
Note, that W and E refers to policy violations, not lintian errors (which
would be written to stderr).

The <tag> describes the policy violation; a <tag> has zero or more
arguments. 

Examples:

    E: logwrites: pkg-without-shlibs-has-shlibs-control-file

-> Policy violation: Package `logwrites' does not contain any shared
libraries, but has a `shlibs' control file.

    W: staroffice3: postrm-calls-ldconfig

-> Possible policy violation: Package `staroffice3' calls `ldconfig' in
its postrm script, which may be dangerous during upgrades. (Since lintian
cannot know--yet--whether the postrm script checks for an `upgrade', this
is only a `warning' and has to be checked `by hand'.)

    E: doc-linux-text: usr-doc-symlink-without-dependency # doc-linux

-> Policy violation: Package `doc-linux-text' contains a 
`/usr/doc/doc-linux-text -> doc-linux' symbolic link, but does not depend
on doc-linux.


1st check: copyright files
==========================

The first check I've written checks binary packages for compliance with
our /usr/doc/<pkg>/copyright policy. Tags produced by this script: 

   E: no-copyright-file             /usr/doc/foo/copyright not found
   E: copyright-file-compressed     /usr/doc/foo/copyright.gz exists
   E: copyright-file-is-symlink     /usr/doc/foo/copyright -> foo
   E: usr-doc-symlink-without-dependency   /usr/doc/foo -> bar without
                                           dependency on bar
   E: usr-doc-symlink-to-foreign-package   /usr/doc/foo -> bar, bar from
                                           other source pkg
   E: old-style-copyright-file      /usr/doc/copyright/foo exists

I ran this script over the complete dists/unstable archive (including
non-us) with timestamp `Fri Jan 23 23:00:01 UTC 1998' and received 344 (!) 
errors. (67 of these bugs have already been filed some time ago.) Now the
question is what to do with the rest. Reporting them as bugs as really
_very_ simple now, but I wanted to get sure everyone here agrees with the
procedure first. 

Here is the top of the list (sorted alphabetically) to give you an
impression:

E: apache-dev: usr-doc-symlink-without-dependency # apache
E: apache-doc: no-copyright-file
E: apache-ssl: no-copyright-file
E: apcalc-dev: usr-doc-symlink-without-dependency # apcalc
E: apple2: copyright-file-is-symlink
E: at: no-copyright-file
E: awe-drv: no-copyright-file
E: awe-midi: no-copyright-file
E: awe-netscape: no-copyright-file
E: battleball: copyright-file-compressed
E: bitchx-bin: usr-doc-symlink-without-dependency # bitchx
E: bitchx-lib: no-copyright-file
E: blt-dev: usr-doc-symlink-without-dependency # blt
E: blt2: no-copyright-file
E: bridge: old-style-copyright-file
E: bsdmainutils: copyright-file-compressed
E: bzip: copyright-file-compressed
E: cfengine: no-copyright-file
E: chinese-big5: copyright-file-compressed
E: comerr2g: no-copyright-file
[...]

Should I simply file these bug reports (with some explanation, of course)?


2nd check: shared libraries
===========================

The shared library check script detects the following policy violations:

#   E: shlib-with-executable-bit
#   W: shlib-with-bad-permissions       file permissions != 644
#   W: shlib-without-dependency-information
                   -> shlib not linked with `-lc'
#   E: ldconfig-symlink-missing-for-shlib
#   E: ldconfig-symlink-before-shlib-in-deb
# 
# (a foo-dev package should contain a symlink foo.so -> foo.so.0)
#   E: dev-pkg-without-shlib-symlink
#      (==> check does not work correctly yet, since -dev packages usually
#      don't contain the shared libraries itself)
#   E: non-dev-pkg-with-shlib-symlink
#
# (check out the packaging manual for details:)
#   W: preinst-calls-ldconfig
#   W: postrm-calls-ldconfig
#
#   E: no-shlibs-control-file
#     (-> a package which includes a shlib has no shlib control file)
#   E: pkg-without-shlibs-has-shlibs-control-file
#   E: duplicate-entry-in-shlibs-control-file
#   E: shlib-missing-in-control-file
#   W: obsolete-shlib-entry-in-control-file

Running this check over the archive (timestamp one week ago) resulted in
665 (!) warnings and errors. Note, that as checking for shared libraries
is much more complicated than checking for copyright files, this check
produces much more wrong errors/warnings. Here are a few example messages:
(long lines have been wrapped)

W: metro-motif-aout: postrm-calls-ldconfig
W: metro-motif-devel: postrm-calls-ldconfig
W: metro-motif-lib: postrm-calls-ldconfig
E: logwrites: pkg-without-shlibs-has-shlibs-control-file
W: logwrites: shlib-without-dependency-information
usr/lib/logwrites.so.1.1
E: kdelibs0g: shlib-with-executable-bit usr/lib/libjscript.so.0.0.1
-rwxr-xr-x
E: kdelibs0g: shlib-with-executable-bit usr/lib/libkdecore.so.0.0.11
-rwxr-xr-x
E: kdelibs0g: shlib-with-executable-bit usr/lib/libkdeui.so.0.0.10
-rwxr-xr-x
E: kdelibs0g: shlib-with-executable-bit usr/lib/libkfm.so.0.0.1 -rwxr-xr-x
E: kdelibs0g: shlib-with-executable-bit usr/lib/libkhtmlw.so.0.0.12
-rwxr-xr-x
E: kdelibs0g: shlib-with-executable-bit usr/lib/libmediatool.so.0.0.7
-rwxr-xr-x
E: kdelibs0g: ldconfig-symlink-before-shlib-in-deb usr/lib/libjscript.so.0
E: dpkg: shlib-with-executable-bit usr/lib/libdpkg.so.0.0.0 -rwxr-xr-x
E: dpkg: non-dev-pkg-with-shlib-symlink usr/lib/libdpkg.so.0.0.0
usr/lib/libdpkg
.so
E: dpkg: no-shlibs-control-file
E: binutils: shlib-with-executable-bit usr/lib/libbfd.so.0.0.0 -rwxr-xr-x
E: binutils: shlib-with-executable-bit usr/lib/libopcodes.so.0.0.0
-rwxr-xr-x
E: binutils: ldconfig-symlink-before-shlib-in-deb usr/lib/libbfd.so.0
E: binutils: no-shlibs-control-file
W: binutils: shlib-without-dependency-information usr/lib/libbfd.so.0.0.0
W: binutils: shlib-without-dependency-information
usr/lib/libopcodes.so.0.0.0

I see the following options now:

   a) report all messages as maintonly bugs
   b) report only some messages as maintonly bugs (perhaps for 20
packages) and wait what the reaction is and how many bugs in lintian are
discovered, before reporting the other bugs
   c) post the complete list to debian-devel and let the maintainers
fix some bugs before filing bug reports
   d) put the complete list on my web site and send each maintainer a
private note to check the list (and report bugs later)
   e) ...

Any comments are welcome!


Thanks,

Chris

--                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian has a logo!    schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                    
Check out the logo     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
pages at  http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: