Package: incus-base
Version: 6.0.3-4
Severity: serious
Justification: file loss in upgrade
Control: affects -1 + incus
User:
helmutg@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)