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

Re: Lintian based autorejects



* Steve Langasek <vorlon@debian.org> [091101 11:23]:
> Some problems I find with this list:

I think some of those complaints show a general disagreement about
what aims Debian has. Are we here to gain for quality or is allowing
the maximum amount of (free) software the primary goal?

> E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate
> [...]
>
> This one has been mentioned previously in the thread.  Yes, it's a blemish
> in the package to list "Upstream Author(s)", but the lintian maintainers
> have correctly marked this as being of "normal" severity.  We should not be
> blocking packages from the archive for such low-severity issues; please drop
> this check.

I think a suggestion that a bug filed about this should be "normal" and
rejecting a package targeted at unstable or experimental with this can
be fully compatible.
Already having a problem with that in the archive is no problem (and
there is no reason to stall testing migration because of it). But why
should we allow a new version of this package uploaded? Even in case of
an NMU its no effort at all to fix it.

> E: ftp-master: section-is-dh_make-template
> [...]
>
> Sections in source packages have minimal impact; the section that matters is
> the one specified in the archive override.  There's no reason that the
> invalid default value given by dh_make should result in a package being
> rejected, when arbitrary other values for the field would not.  Please drop
> this check.

Again, even if it has no big impact, why should we allow it? It's not
hard to find (lintian will tell it), and not at all hard to fix.

> E: ftp-master: executable-in-usr-share-doc
> [...]
>
> Clearly a bug, but just as clearly not anything that breaks the package to
> the point of making it unsuitable for the archive.  Please drop.

Again, what is the advantage of dropping it? As files in /usr/share/doc
should not be needed for the package to function (otherwise it is an
even more serious bug), the biggest possible cost for the maintainer to
fix this is a single rebuild.

	Bernhard R. Link


Reply to: