Hi! On Sat, 2010-07-03 at 13:28:26 -0700, Russ Allbery wrote: > Tobias Frost <tobi@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. Yeah, but I've also witnessed (and reported) several of those for shared libraries on SONAME bump. > 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 Seconded. regards, guillem
Attachment:
signature.asc
Description: Digital signature