Package: systemd-sysv
Version: 255~rc1-4
Severity: serious
Justification: silent file loss in upgrade
User: helm...@debian.org
Usertags: dep17p7
Hi Luca and Michael et al,
while preparing patches for molly-guard, I figured an upgrade file loss
scenario for systemd-sysv. This is unfortunate on multiple accounts and
I cannot offer a solution at this time.
Let me start with a reproducer and move on to an explanation.
mmdebstrap \
bookworm \
/dev/null \
http://deb.debian.org/debian \
--variant=apt \
--include=molly-guard,systemd-sysv \
--customize-hook='sed -i -e s/bookworm/sid/ "$1/etc/apt/sources.list"' \
--chrooted-customize-hook="apt update" \
--chrooted-customize-hook='apt-get -y upgrade --with-new-pkgs' \
--chrooted-customize-hook='apt-get download libsystemd-shared
libsystemd0 libudev1 systemd systemd-sysv' \
--chrooted-customize-hook='echo "molly-guard:all deinstall" | dpkg
--set-selections' \
--chrooted-customize-hook='dpkg --auto-deconfigure --unpack *.deb' \
--chrooted-customize-hook="dpkg --configure -a" \
--customize-hook='ls -la "$1/usr/sbin/halt"'
In testing the molly-guard patches I noticed an odd behaviour.
Occasionally, dpkg would unpack sid's systemd-sysv before removing or
upgrading bookworm's molly-guard. This is surprising given that
systemd-sysv declares versioned Conflicts for molly-guard. I reduced
this into a minimal test case and discussed it with Guillem Jover. He
suggested that this behaviour is covered by debian policy section §6.6
and after reading it over and over, I agree. I now consider the
explanation of Conflicts in §7.4 misleading. Since apt developers were
also surprised, I filed #1057199 against debian-policy to ask for
clarification. That said, we won't be changing how dpkg works in
bookworm and hence have to find a solution that works with the current
implementation. Fundamentally, we allow unpacking a package (e.g.
systemd-sysv) while conflicting packages are still installed as long as
those conflicting packages are scheduled for (temporary or permanent)
removal.
Hence the test case above crafts a bookworm installation containing both
systemd-sysv and molly-guard. It then proceeds to upgrading systemd-sysv
and removing molly-guard. While this is a bit of an artificial
reproducer bypassing apt, I managed to reproduce this with apt in more
complex upgrades. While the moratorium is formally lifted, the release
team still classifies file loss due to /usr-merge as RC bugs.
Let me stress that this scenario does not involve a molly-guard from
trixie or sid. It relies purely on the molly-guard released with
bookworm. So there is nothing that molly-guard can do to assist here. A
similar situation happens when upgrading molly-guard rather than
removing it. The updated molly-guard.preinst is only run after
systemd-sysv has been unpacked and files have been lost.
I appreciate ideas, proof of concepts and other forms of help. I do
request patience with uploading a fix though. I've got the molly-guard
patch wrong about four times already. Please let us pass a solution
through review and extensive testing before uploading.
Helmut
