[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, 2006-05-17 at 09:19 +0100, Adam D. Barratt wrote:
> On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <lionel@mamane.lu>
> wrote:
> > On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote:
> >> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti:
> [...]
> >>> AFAIK, vilolating policy always waarent a serious bug:
> [...]
> >> This is not what Steve Langasek tells me (or else I'm seriously
> >> misunderstanding). The etch_rc_policy.txt document is what documents
> >> what is release critical.
> >
> > Doesn't that mean the bug is severity serious, but should be tagged
> > "etch-ignore"? That's what we did with sarge, if I remember well?
> No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it
> for the release of foo". Any bug tagged "etch-ignore" is by definition RC
> the moment etch is released.
> The exact definition of what qualifies for a severity of serious or above
> (i.e. RC) are the purview of the Release team, as noted at
> http://www.debian.org/Bugs/Developer#severities. A "severe violation of
> Debian policy" is one which violates the current release policy, as laid out
> by the Release team.

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.

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, 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].

At least with debian-policy, any changes must actually be discussed and
viewed by several people, which increases the probability that this type
of error is found and corrected, hopefully before it even becomes

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.

[0] 5g of the the etch RC policy [sic][1]:
Scripts must include the appropriate #! line, and set executable.
The package providing the script must Depend: on the appropriate
package providing the interpreter.
[1] The text in [0] should say "be set executable" or "be executable"
or even "have been set executable", instead of "set executable".

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: