On Tue, Aug 22, 2023 at 12:17:58PM +0200, julien.pu...@gmail.com wrote:
> Section 7.6 is about partial and complete replacement according to its
> very first paragraph ("two distinct purposes"), but doesn't make the
> difference afterwards and I think that's the source of our
> disagreement. The whole section 7.6 is in fact only about
> Breaks+Replaces -- but that makes only one use, and clearly the
> "complete replacement" one where's the "partial replacement" use?Replaces does not distinguish between partial and complete relacement. Note that Replaces is mostly irrelevant to apt and mainly interpreted by dpkg. It allows the replacing package to take over files from any package that matches a Replaces declaration. When such replacement happens, the ownership of the replaced file may transition from the replaced package to the replacing package even if the replaced package still is installed. The replaced package now has fewer files than it originally was installed with. This situation is usually temporary, because it is prevented to endure by also using Breaks. Usually a complete replacement (where a package goes away entirely) is augmented with Conflicts as that forces the replaced package to be removed. The Conflicts helps apt consider such solutions that require removals. > As I interpret Breaks+Replaces as meaning complete replacement, and > since libcoq-mathcomp-classical isn't a complete replacement, I am > reluctant to add Replaces - that's why 0.6.4-2 doesn't have it. This is not a common interpretation. Maybe https://wiki.debian.org/PackageTransition helps? > As I understand it, the Breaks means dpkg will know about the file > conflicts so foo-data 1.2-3 and foo 1.2-2 won't both end up on the > system. But the Replaces tells it that foo-data 1.2-3 can overtake foo > 1.2-2. So it should remove foo 1.2-2 and install foo-data 1.2-3 as > requested. No more foo on the system! And that's wrong... No. Breaks merely says that the packages may not be configured at the same time. You may deconfigure one and configure the other or vice versa. Of course having packages in unpacked state on your system is an undesirable state from an apt pov, so usually that ends up with a removal of the other, but it really is weaker than that. > Whatever this discussion gives, I think debian-policy will need a > clarification... I encourage you to really improve the policy wording once there is a common understanding. If you send a policy patch, please X-Debbugs-Cc me. I'm happy to review and second it if appropriate. Helmut
