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
produce.)
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
maintainer.
* 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
policy.)
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
March).
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
installation.
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
other.
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.
Ian.
Reply to: