On Mon, Feb 19, 2024 at 09:48:00AM +0000, Matthew Vernon wrote: > To check I have understood correctly: one may see loss of files when doing > dpkg -i of a package where it Conflicts: with an installed package?
Unfortunately, this is real. apt avoids this, because it recognizes that it can remove the conflicted package before installing the other one. > If that's so, then I think it increases my unhappyness about this situation. > I can understand "do upgrades with apt, that's the tooling for the job", and > we had already talked about adding something to release notes to describe > what manual actions that one might take during an upgrade were dangerous, > but "dpkg -i foo.deb where foo.deb Conflicts with something you have > installed" seems like the sort of thing one really might reasonably do > during an upgrade that has got stuck for some reason or other. TBH, most of the time where I resort to dpkg -i foo.deb, foo was already unpacked and I try again. In that scenario, apt will have resolved the conflict already. For the basic DEP17 P1 problem we now have more nuances of mitigations that are spelled out in the DEP17 document. The basic "upgrade Replaces to Conflicts" M7 mitigation is what we see failing when using dpkg -i above. It can be augmented with temporary (preinst -> postinst) protective diversions M8 to cover this case. Note that just using those protective diversions M8 in isolation actually is unsafe in theory as well. As we remove the diversions in postinst, we may still loose files after that point when unpacking a package that we moved a file from and then removing it again. Such a package cannot be configured (due to Breaks), but it can still cause a file to be lost. In a non-aliasing context, the declared Replaces would ensure that the file is not stolen. We can also extend those protective diversions M8 beyond postinst. This is what we'll be doing for e.g. pam #1062802 and tirpc #1062801. This will leave a completed trixie installation with lots of crazy diversions, but there is no known way to break these with operating dpkg in interesting ways. I note that time64 has added quite some of these diversions (in experimental). It then becomes the question of how many packages should have their protective diversions persisted rather than temporary. When we persist them, we can remove them in forky and drop the removal code in forky+1, which is a long time to carry cruft. Helmut