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

Re: Dependencies on shared libs, take 2

Felipe Sateler <fsateler@gmail.com> writes:
> Russ Allbery wrote:

>> The primary barrier to enforcing the use of lintian is #243976. lintian
>> needs to get much better about identifying the source of checks, the
>> certainty that something is wrong, and the severity level so that dak
>> can run lintian in a very specific way to only reject packages with
>> fairly certain errors according to sources with the strength of Policy.

> man lintian says that when the exit status is 1, policy violations have
> been detected.

man lintian lies.  :)  An exit status of 1 just means that lintian found
errors, not all of which are policy violations, and not all of which are
definitely package problems.  Right now, lintian only has three levels of
classification of tags, on a single axis.  It needs to gain three axes of
classification: severity, certainty, and source.

> As a first step, dak could check the exit code, and reject packages when
> it is 1, forwarding the lintian output to the maintainer (since E tags
> have high certainty, right?).

They *usually* do, but not all E tags are certain problems.  Of course,
maintainers could use overrides.

It's probably a workable idea, but it's not a slam-dunk.  If I can enhance
lintian so that you can say "show me only Debian Policy 'must' violations
about which you're certain," it would be a slam-dunk.

> This way, although tests won't be comprehensive, they would better than
> the current status quo. If a test result is indeed a false positive, the
> maintainer should have filed a bug to lintian and/or provided an
> override file before doing the upload.

I try to be a very responsive maintainer, but I'm a little scared of being
a gating factor for the archive.  :)  But I guess there are overrides.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: