Goswin von Brederlow wrote: >> Package with file conflicts should use Conflicts, not Breaks if they >=20 > And nowhere does it say that. This bug is about making policy say that.=
Well, right. > But that is a bug in dpkg. Dpkg does not check all reverse dependencies= > when a package is installed. The "doing the breaking" package still > Replaces the "broken" package and there should therefore be no overwrit= e > conflict. I considered Replaces is one-side relation... >> Also, generally, this phrase makes impossible for high-level package >> manager to know if two packages, one of which breaks another, have >> conflicting files or no, which has impact of generating sequence of dp= kg >> calls when dependencies is so tight that high-level package manager >> should break some dependencies temporarily. Plus, I don't see the >> rationale why Breaks+Replaces should be used instead of >> Conflicts+Replaces - with that setup upgrade also goes smoothly. >=20 > No. They can trivially see if two packages have conflicting files. Ther= e > is a Replaces entry in the package. Two package with conflicting files may not have Replaces if they are tota= lly different. > The rational for using breaks instead of conflicts is that it imposes a= > much weaker condition on the sequencing of packages and avoids > temporarily removing (essential) packages. Something that happened in > apt and is extremly anoying, since you have to type in that long > sentence, and dangerous. It just isn't sufficient in combination with > Replaces. I understand this point. Well, I have not a better solution for this prob= lem, so then I transform my report to clarifying what do to in reverse-Replace= s case, because it's not covered by policy. --=20 Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
