Re: lintian -- detecting hundrets of bugs within seconds...
First, I"ve read the rest of this thread (so far, anyway!), and
I agree with the general idea temporary overrides via
the changes file, and permanent overrides indicating exceptions
to policy. But:
On 30-Jan-98, 07:46 (CST), joost witteveen <joost@rulcmc.leidenuniv.nl> wrote:
> For example, policy for libraries is written with 'normal' libraries
> in mind. For fakeroot I probably also break current/future policy,
> as fakeroot comes with a shared library, but doesn't have the major
> version number in the package name. Now for nearly every library this
> is a very bad idea, but there's really nothing that would suggest to
> me that having major numbers in fakeroot's name is good.
I have a strong objection to providing exceptions to policy because
the maintainer "thinks there's no good reason to follow policy for my
particular package". Policy exceptions should be provided only when
there is a strong, mutually agreed on reason to provide the exception
for that particular package. Note that I'm not claiming that fakeroot
doesn't have sufficient reason, just that they way Manoj phrased that
particular sentence raised warning flags for me.
> Also I'm not sure we should allow/advice maintainers to upload packages
> with lintian overrides in them, just because the new upload contains
> (signifficantly) less bugs than the old one. Gcc also doesn't say
> "OK, I cannot find this #include file, but at least this time there's
> only one misspelled #include file, so let's generate a .o anyway",
> and dpkg-buildpackage also stricktly refuses to build any package that
> it finds errors in (and dpkg-* also does sanity checks, like lintian).
And so they should. Note also that gcc sometimes says "What you are
doing is a violation of normal C programming practice, but I'll go ahead
and generate the .o file, because that violation may be temporarily
acceptable to you." Some policy requirements are not essential to
program functionality, and temporary violations may be acceptable
so that others who need that functionality can continue their
work. By putting that kind of override in the changes files,
you do two things:
1. Everytime the maintainer uploads, they have to make explicit entries
to provide that override. Eventually, the pain of fixing the problem
becomes less than the pain of ignoring it :-).
2. The users of the package see what policy violations exist in the
package, and can choose to use it or not depending on their needs.
> 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.
Again, I don't think the maintainer should be allowed to unilaterally
decide to ignore Debian Policy. I think it should require a blessing
from Christian (or whoever becomes the Policy Manager).
Steve
--
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: