Package: incus-base Version: 6.0.3-4 Severity: serious Justification: file loss in upgrade Control: affects -1 + incus User: helm...@debian.org Usertags: dep17p1
Hi, you moved the systemd units formerly present in incus to the incus-base package. The way this is done is normally correct and works for trixie -> sid upgrades. Unfortunately, the earlier version has also been backported to bookworm-backports and there the systemd units are installed into the aliased location. Therefore and upgrade from bookworm-backports to sid may presently loose the systemd units. This bug serves as a migration blocker. For more information refer to https://subdivi.de/~helmut/dep17.html section P1. The failing scenario is rare. People upgrading from trixie to sid will be unaffected as there is no aliasing in trixie. People running bookworm-backports will most likely upgrade to some eventual 6.0.3-4~bpo12+1 which will also have working Replaces and from there they may be upgrading to trixie at a later time. It is the rare situation from the aliased + previous package organization to the canonicalized + reorganized packages that is prone to loss. Given this rarity, I suggest going with a rather weak mitigation that will only work reliably when upgrading with an apt-based package manager (and can leave failing scenarios behind when doing upgrades with dpkg directly). It is (DEP17 M7): -Replaces: incus (<< 6.0.3-3~) -Breaks: incus (<< 6.0.3-3~) +Conflicts: incus (<< 6.0.3-3~) Then apt will prefer to unpack the updated incus (releasing the systemd units) before unpacking incus-base and thus avert the file loss situation. In other cases, I've suggested stronger mitigations, but here my expectation is that the scenario is mostly artificial (assuming that you do another bookworm-backports upload and people upgrade to it). Do you agree with the reasoning? If yes, please move forward and include "DEP17 P1 M7" in debian/changelog. Helmut
