Tobias Frost <t...@frost.de> writes:
> Looking at #262257, as an exampple, there are packages which declares
> conflicts for whatever reason. However, the reason is NOT, that thec
> packages could not co-existent on the same system (For the example,
> retchmail could be also installed with fetchmail -- they do not
> interfere)
> My wishlist-entry would be to clarify, tha conflicts should only be
> used, if the packages "won't do" if both installed... (as the word
> "conflict" implies. The reason "the other package is doing the same, so
> conflict on it to prevent both installed" is -- IMHO -- not the
> intention of conflicts
This really should be common sense, but it doesn't hurt to say it
explicitly, which I don't think we were doing before. Here's a patch that
implements that.
Objections or seconds?
diff --git a/policy.sgml b/policy.sgml
index bad28af..efda2a1 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4778,6 +4778,15 @@ Build-Depends: foo [linux-any], bar [any-i386], baz
[!linux-any]
</p>
<p>
+ Neither <tt>Breaks</tt> nor <tt>Conflicts</tt> should be used
+ unless two packages cannot be installed at the same time or
+ installing them both causes one of them to be broken or
+ unusable. Having similar functionality or performing the same
+ tasks as another package is not sufficient reason to
+ declare <tt>Breaks</tt> or <tt>Conflicts</tt> with that package.
+ </p>
+
+ <p>
A <tt>Conflicts</tt> entry may have an "earlier than" version
clause if the reason for the conflict is corrected in a later
version of one of the packages. However, normally the presence
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aaq8ux79....@windlord.stanford.edu
