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

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

On Fri, 30 Jan 1998, joost witteveen wrote:

> In an attempt to save the world from disaster, Santiago Vila wrote:
> > On Fri, 30 Jan 1998, joost witteveen wrote:
> > 
> > > So, in short: I think overrides (even easy ones) are essential, but
> > > I think they only should be used when the maintainer thinks his package
> > > is so special that some part of debian-policy doesn't apply to his
> > > package.
> > 
> > I agree. Since package priorities (the override file) are managed by Guy
> > Maor, ftp.debian.org maintainer, I think it would be ok to have a "global
> > override file for lintian", maintained by Christian Schwarz, policy
> > manager. How does this sound?:
> Actually, I like it. That way the overrides sort-of become actual
> debian policy, like "Christian writes the policy, Guy approves
> the exceptions".

Nice idea, but I don't think it could replace the changelog idea

First of all, recall that lintian overrides will only be necessary for
`error' messages, not for warnings. (dinstall will not reject a package
because of warnings.)

With that, there are three situations where lintian overrides will be

 1. A known policy exception for one package. 
 2. A bug in lintian: lintian reports a policy violation by mistake.
 3. The upload is important and the maintainer does not have time to
    fix the policy violation immediately.

(Note, that in either situation the maintainer will know _before_
uploading the package that lintian will report an error, since he/she is
expected to check his/her packages at home with lintian before uploading

For the first situation (#1) a global override file will probably be good.

For #2, lintian should be fixed ASAP.

For #3, the package should be fixed ASAP.

So in either case, it's only required to bypass a lintian check for a
single upload. Doing so should be very easy for the maintainer but also
visible to everyone else (without having to look inside the package).
That's why I think the changelog entry is the right place for it: The
changelog entry already describes the upload (target distribution,
version, changes, upload person, urgency, bug fix info, etc.) and it's
IMHO logical to add the lintian info.

The only disadvantage I see is that the changelog entry may get a bit long
if lintian discovers lots of problems for a package. (For example,
yesterday I wrote a md5sum check which checks the md5sums files of
packages (if these are provided) against the actual md5sums of all files
and ran it over the full archive. It turned out that one of the picon-*
packages has an empty md5sums control file which produced a few hundred
lintian error messages--just for that one package :-)

But this situation could easily be worked around if we allow a general
"bypass-lintian-completely" override. 

In summary, I think there will be several sources for overrides and
lintian will put them all together when examining a single package. 
However, doing everything with a globally maintained list is IMHO too much
work and would not fit into the design of lintian. 




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