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

the intention of lintian

[From the reactions of some people to my previous postings about "lintian" 
I see the need for a clarification about the intention of lintian. Hope
this mail answers all open questions. If not, please drop me a note.]

Packaging has become complicated--not because dpkg is complicated
(indeed, dpkg-deb is very simple to use) but because of the high
requirements of our policy. If a developer releases a new package, he/she
has to consider hundrets of guidelines to make the package `policy

All parts of our policy have been introduced by the same procedure: Some
developer has a good idea how to make packages more `unique' WRT a certain
aspect--then the idea is discussed and a policy proposal is prepared. If
we have a consensus about the policy change, it's introduced in our

Therefore, our policy is *not* designed to make life harder for the
maintainers! The intention is to make Debian the best Linux distribution
out there. With this in mind, lots of policy changes are discussed on the
mailing lists each week.

But changing the policy is only a small part of the story: Just having
some statement included in the manual does not make Debian any better.
What's needed is that policy becomes `real life,' i.e., it's _implemented_
in our packages. And this is where lintian comes in: lintian checks
packages and reports possible policy violations. (Of course, not
everything can be checked mechanically--but a lot of things can and this
is what lintian is for.)

Thus, lintian has the following goals:

  1. To give us some impression of the `gap' between theory (written
     policy) and praxis (current state of implementation). 

     From the results of the first two lintian checks I implemented, I see
     that there is a big need to make this gap smaller. Introducing more
     policy aspects is worthless unless they are implemented. We first
     should fix packages to comply with current policy before searching
     for new ways to make policy more detailed. (Of course, there are
     also important policy changes that need to be introduced--but this
     is not what's meant here.)

  2. To make us re-think about certain aspects of our policy.

     For example, it could turn out that some ideas that once sounded
     great in theory are hard to implemented in all our packages--in which
     case we should rework this aspect of policy.

  3. To show us where to concentrate our efforts in order give Debian a
     higher quality.

     Most of the release requirements will be implemented through policy.
     That is, a new policy manual will be released in a few days which
     will cover (nearly) everything that's necessary for a package to be
     ready for Debian 2.0. The lintian reports will provide an easy way to
     compare _all_ our packages against policy and keep track of the
     fixing process by watching bug reports. Note, that all this can be
     done _automatically_.

  4. To make us avoid doing the same mistakes all over again.

     Being humans, it's natural for us to make errors. Since we all have
     the ability to learn from our mistakes, this is actually no big
     problem. Once an important bug is discovered, a lintian check
     could be written to check for exactly this bug. This will avoid
     the bug to appear in any future revisions of any of our packages.

This said, I hope everyone understands what lintian is designed for. 

As always, comments are welcome!



--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
 CS Software goes online! Visit our new home page at

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: