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

Re: Mass bug filing: failure to use invoke-rc.d when required

On Wed, May 17, 2006 at 12:37:56PM +0000, Brian M. Carlson wrote:
> Then when are we removing the debian-policy package from the archive?
> But seriously, if violating Debian Policy has no consequences, then it
> probably won't be followed.  As it stands now, Policy is useless because
> the worst that can happen is an important bug, which can be safely
> ignored almost forever.

The release team is not going to enforce all policy violations as RC bugs,
because although all policy violations should be considered bugs, not all of
them should warrant delaying the release or removing the package from the

So whether or not such bugs are labelled "serious" is irrelevant, because
labelling them "serious" would just mean that sev: serious no longer
correctly identifies RC bugs and we would then need some other way to
separate RC from non-RC serious bugs.

> As far as the etch_rc_policy.txt, there are at least 10 different issues
> with that document that may be unintended, one of which is that as it
> stands now, all perl-using packages *must* depend on perl-base,

Perl-base is Essential: yes.  It is not a bug to not depend on an Essential
package, so nor is it an *RC* Bug to not depend on an Essential package.

> and all python-using packages *must* depend on the package providing the
> interpreter (/usr/bin/python is *not* an interpreter, merely a symlink),
> such as python2.3, python2.4, or python2.5[0].

This is a lame argument.  The RC policy says "package providing the
interpreter", not "package containing the binary".  /usr/bin/python is
clearly an interpreter provided by the "python" package.

Patches to improve the wording of the RC bug policy are certainly welcome,
but I'm not going to spend a lot of my own time trying to idiot-proof it;
both of your examples seem terribly contrived to me, and if the etch RC
policy is read with the understanding that it identifies those violations of
*existing* policy that are RC, rather than attempting to declare *new*
policy, I don't see that there's any reason for confusion here.

> Finally, I would prefer if some tag existed that would indicate that a
> bug is not a concern for the release but is still a major error in terms
> of Debian Policy.  I understand that such tags *do* exist, and that they
> are called "sid" and "experimental".  I also understand that these are
> deprecated with BTS version tracking; however, since these tags have the
> desired effect, and there are no other ones with equivalent effect, I
> will use them for all of my current and future bugs.

No, the "sid" tag does not have the desired effect.  It has the effect of
causing britney to regard the version of the package in sid as having an RC
bug, and take it into consideration when evaluating the sid version of the
package for propagation to testing.  Please don't try to use tags this way,
it's inconsistent with how the software works (and is intended to work,

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: