On Mon, 3 Mar 2025 14:43:30 +0100 Helmut Grohne <hel...@subdivi.de> wrote: > [Y]ou 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.
I would expect this scenario to be exceedingly rare, bordering on purely theoretical. I do intend to provide an updated backport with the packaging changes; to be affected a user would have to avoid updating their bookworm system before upgrading to trixie. As we have a few months before the trixie stable release, I think the odds of someone not running `apt update && apt upgrade` between the upload of an updated backport and the trixie upgrade to be very low. (I suppose someone could also upgrade to testing in the window between Incus migrating to testing and an updated backport being available, but again I think that's pretty unlikely.) > 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. I am inclined to lower the severity of this bug, so Incus can migrate to testing, then close it after a new backport has been uploaded. If Incus had been part of the bookworm release, I would be more concerned about possible breakage during an upgrade to trixie, but Incus has only ever been available via backports for bookworm. As such, it's more of an "opt-in" situation with users needing to explicitly install it from backports. I also intend to backport the 6.0.4 release later this month, which will be another incentive for people to do an update well in advance of the trixie release, further minimizing the likelihood of someone actually encountering this upgrade issue. Mathias
signature.asc
Description: This is a digitally signed message part
