Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
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
Reply to: