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

Re: repack upstream sources or overrides ?



Bas Wijnen <shevek@fmf.nl> wrote:

> On Tue, Nov 15, 2005 at 12:59:49PM +0100, Frank K?ster wrote:
>> 
>> I don't know how communication with the ftp-masters works these days;
>> ideally they would read through files in the debian dir (what about
>> README.ftp-masters :-)...) and find your note about the reasoning.  I
>> would not just add a lintian overrides without having the package
>> double-checked by a person who really understands the issues and
>> verifies that the files will really be out of effect.
>
> I am confused about the purpose of lintian overrides.  Can someone explain it
> to me, please?
>
> I thought an override would be in order when lintian complains, but there
> isn't really a bug.  In other words, in case of a false positive.  A lintian
> bug report may be in order as well, as the reject-faq says.

I agree with that.

> In this case, the warning is not wrong at all.  It is a bug, and it needs to
> be fixed.

ACK.

> In this case, it can only be fixed upstream (I'm assuming here that
> this is not enough reason to repackage the tarball).  Upstream has also agreed
> to fix it in the next release.
>
> So I thought that a lintian warning/error should be seen as a bug in the
> package.  An override would be a WONTFIX tag on it, effectively closing the
> bug.

In this case, I'd rather say that it's a "severity normal" tag, as
opposed to the RC (Reject Critical ;-)) severity the lintian error
normally has.  The better choice is to communicate with ftp-master; but
if it has to be assumed they won't even look at the package if there's
this lintian error, an override might be justified.

But you are right - if it was my package, I'd just upload it with the
bug and the lintian error, and an explanation in the changelog and
README.Debian file.  If it's rejected due to the lintian error, and
there's no reaction on subsequent complaints, you can still reupload it
with a lintian override, and still get the package into unstable faster
than it was usual a year ago...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: