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

Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug

(Redirected off the bug report as the BTS makes a poor mailing list
archive for the kinds of extensive threads that TC discussions

Eugene V. Lyubimkin writes ("Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug"):
> Please reaffirm that Debian bug #575786 against 'dpkg' package has
> 'serious' severity because of violation §7.6.2 of the Debian policy.

Firstly, process questions.  It seems to me that:

  * In the first instance the severity of the bug is a matter for the
    maintainer.  The maintainer has declined to increase the severity.
    So the request is in some sense a request to overrule the

  * As regards the boundary between not-serious and serious, this is a
    matter for the release team.  It seems unlikely to me that the
    release team want to be bothered with this, or that we or they
    would consider this situation a release critical bug.  However if
    we think there is a plausible case to be made that this is a
    release critical bug we should take input from the release team.

  * The reference to policy is a IMO red herring.  As I've said
    before, even if policy purports to make certain bugs release
    critical, that is not binding on the release team, it's not
    binding on maintainers unless the release team says it is, and
    it's not binding on the TC.  (Yet again we have some fallout from
    the campaign to decide every situation by looking only at rules in

    Having said that, policy in this area is the technical
    specification for the packaging system.  So either the packaging
    system should do what policy says, or policy should be changed.

On to substance:

This bug report is confused.  It appears to conflate two issues:

 1. You can't Replace (file overwrite, ie Replaces-without-Conflicts)
    a virtual package.  This seems to be the original complaint (29th

    This is in accordance with the spec in 7.6.1.

    Is this correct ?  Yes, it is.  If you Replace a package then you
    end up with the replaced package partially present - some of its
    files have been overwritten and taken over by the Replacing
    package.  This does not make sense unless the Replacing package
    has a very clear idea of what the Replaced package may contain,
    which means that a virtual package doesn't really make sense.

 2. If two packages Replaces/Conflicts/Provides the same virtual
    package you can't just "dpkg -i" to swap between them.  This is
    demonstrated in Eugene's message on the 9th of May, and the test
    case mentioned by Raphael does it.

    This appears to be contrary to the spec in 7.6.2, which describes
    the situation with mail-transport-agent.  The packages seem mostly
    do do what the policy manual says but dpkg doesn't honour it.

    So which of spec or implementation is correct ?  I think the
    implementation is correct and the spec is wrong.

    Replaces is intended to allow the packaging system to
    automatically remove obsolete packages.  It is not intended as a
    workaround for the fact that dpkg won't simply exchange one
    Provider/Conflicter for another if the old package is marked for

    Indeed this is made clear by the first paragraph of 7.6.2, which
    says that it enables the packaging system to decide _which_ of a
    set of conflicting packages to install and which remove.  That's
    obviously not what's going on if all the packages declare Replaces
    against each other (using virtual packages or otherwise).

    It might be nice for dpkg to have a command-line option to
    disregard the installation mark for the conflicting-but-installed
    package in this situation, which would make command-line use of
    dpkg easier.  But Replaces is not what this is supposed to do.  If
    it were, then _every_ Conflicts should also have a Replaces.

    The distinction between apt and dpkg here is a red herring I
    think.  It may be that apt deals with Replaces/Conflicts/Provides
    differently, but it's difficult to say that this is a bug in apt.
    On the analysis I give above, it is a bug in the packages with
    dpkg spots but apt does not.

So I would:

 A. Open a new bug against policy, asking that 7.6.2 be replaced with
    something like this (exercising our power to specify what should
    be in policy):
      Secondly, Replaces allows the packaging system to resolve which
      package should be removed when there is a conflict - see
      Conflicting binary packages - Conflicts, Section 7.4.  This
      usage only takes effect when the two packages do conflict, so
      that the two usages of this field do not interfere with each

      Conflicts+Replaces should be used only to ensure that obsolete
      packages are removed in favour of new packages.  A package
      should not declare Replaces against any non-obsolete package,
      and it should not declare Replaces against any virtual package
      it itself provides.

      (In previous versions of policy there was a recommendation to do
      the opposite.  That was incorrect and inconsistent with the
      purpose of Replaces, and was not fully honoured by dpkg.  See
      Bug#THIS-BUG-REPORT and the associated Technical Committee
      discussion for the rationale.)

 B. Close #575786 as we do not regard the initial report as a bug,
    explicitly upholding the maintainer's position which seems to be
    that dpkg is correct.  Mention in our close message that we are
    dealing with the 2nd issue (Eugene's message of the 9th of May)
    separately, quoting its bug number.

 C. Give a non-binding opinion that we don't believe violations of the
    new text of 7.6.2 to be release critical bugs.


Reply to: