Bug#578854: debian-policy: Wording about Conflicts needs to be clarified

[Goswin von Brederlow <goswin-v-b@web.de>]

Steve Langasek <vorlon@debian.org> writes:

> On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote:
>> I stumbled upon policy 7.4:
>> > A Conflicts entry should almost never have an "earlier than" version clause.
>> > This would prevent dpkg from upgrading or installing the package which declared
>> > such a conflict until the upgrade or removal of the conflicted-with package had
>> > been completed. Instead, Breaks may be used. 
>
>> Looking at this sentence it comes mostly unchanged from the original packaging
>> manual (commit ff1bec10):
>> -         A <tt>Conflicts</tt> entry should almost never have an
>> -         `earlier than' version clause.  This would prevent
>> -         <prgn>dpkg</prgn> from upgrading or installing the package
>> -         which declared such a conflict until the upgrade or removal
>> -         of the conflicted-with package had been completed.  This
>> -         aspect of installation ordering is not handled by
>> -         <prgn>dselect</prgn>, so that the use <tt>Conflicts</tt> in
>> -         this way is likely to cause problems for `bulk run' upgrades
>> -         and installations.
>
>> I think using an earlier than clause is perfectly ok nowadays and it's
>> possibly the right thing to do when moving files around between packages.
>
> No, it definitely isn't ok.  Versioned conflicts still impose significant
> constraints on calculating an upgrade path between releases and contribute
> to upgrade failures.
>
>> Up to now, I always used "Conflicts" for explicit file conflicts and used
>> Breaks for other subtle breakages (interface/API change). So when moving files
>> from one package to the other I used "Conflicts: previous (<< last-version)"
>> and "Replaces: previous (<< last-version)" on the package where the files are.
>
> "Conflicts" is always right for file conflicts, and in that case should also
> *always* be accompanied by Replaces.  The biggest problem, which the Policy
> wording tries to address, is the use of "bare" Conflicts, for things that
> aren't file conflicts:  in that case, a versioned conflicts is almost always
> wrong because what you really mean to express is a versioned Breaks.  And
> it's *that* usage of versioned Conflicts which causes the most problem for
> the package manager.

How about this? In 7.3 replace

  If the breaking package also overwrites some files from the older
  package, it should use Replaces (not Conflicts) to ensure this goes
  smoothly.

with

  If the breaking package also overwrites some files from the older
  package, it must use a "less than" versioned Conflicts (not Breaks) to
  ensure both upgrades and downgrades go smoothly.


And in 7.4 replace

  A Conflicts entry should almost never have an "earlier than" version
  clause.  This would prevent dpkg from upgrading or installing the
  package which declared such a conflict until the upgrade or removal of
  the conflicted-with package had been completed. Instead, Breaks may be
  used.

with

  A Conflicts entry should only have an "earlier than" version clause if
  it coincides with a Replaces clause of the same package and version. A
  Conflicts with an "earlier than" version clause without Replaces
  clause is almost always better done as Breaks.

MfG
        Goswin