Hi developers, I have unfortunate news regarding /usr-merge. I uncovered yet another problem that we haven't seen mentioned earlier. We do not yet know how to deal with it and it may take some time to come up with a good compromise. As a result, please pause further moves from / to /usr. Exceptions: * With more uploads, more systemd units will move. While such moves may trigger the new problem, I expect that to be rare. * Continue fixing RC bugs, in particular those that are due to dh_installsystemd or systemd.pc having moved to /usr. * Continue applying DEP17P7 mitigations for udev rules. Patches for these have been sent by Christian Hofstaedler and a few people from the Cambridge miniconf. These are unrelated. The rest of this mail is lots of funky details for those interested in understanding what went wrong here. Others are encouraged to do something more joyful :) Before we go, let me express sincere thanks to so many people that helped me track this down. In particular, the input of David Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable. Fundamentally, Conflicts do not reliably prevent concurrent unpacking of packages as policy §7.4 may suggest. I have reported this as #1057199. Consequently, what we look at here is situations where Conflicts are used to mitigate file loss in the face of aliasing changes. Debian policy §6.6 is more precise and details that when unpacking a package, conflicting packages may be deconfigured and removed after the unpack. In theory, the difference should not be noticeable, because dpkg accurately tracks ownership of files with respect to packages. Aliasing changes this and can cause file loss. The situation arises when installing or upgrading a package to a version that happens to be in conflict with another package to be removed. A simple example is upgrading a bookworm system with molly-guard and systemd-sysv to sid and in the process deleting molly-guard. A similar issue happens when upgrading a bookworm system with busybox-static to sid and in that process installing busybox and thus removing busybox-static. The situation is hard to come by, because apt tends to remove the package that goes away early when it can. I have implemented a reproducer without apt for systemd-sysv #1057220. There are also situations where apt reproduces this available from the policy bug mentioned earlier. In particular, when one package has versioned Conflicts for another and the other has versioned Breaks for the former, this reproduces with apt. This essentially breaks DEP17 proposed mitigations M7 and M18. I have also locally extended dumat to produce a report of affected Conflicts and am attaching it to this mail. The only packages that have not yet migrated and have this problem are systemd-sysv, busybox/busybox-static and resolvconf and I have filed RC bugs for them. There are other instances in trixie already. I welcome ideas for solving these problems. Let me summarize those I already am aware of. Julian Andres Klode proposes adding a "barrier package" that we may call usrmerge-support (or repurpose usr-is-merged). Affected Conflicts can be moved to the barrier package and the conflicting package would then express Pre-Depends on the barrier package. When the barrier's postinst runs, any conflicting package definitely has been removed and due to using Pre-Depends, the conflicting package definitely has not been unpacked yet. Another option is duplicating affected files (e.g. using hard links) in the data.tar and then restoring lost files during postinst. Depending on what problem we are solving, we may also move to protective diversions (DEP17 M8). It also is not clear how easy it is to reproduce this bug class in an actual upgrade. It took long to find the issue for a reason. Depending on what files go missing, we may get away with asking users to dpkg --audit and then apt reinstall affected packages. That barrier package approach sounds relatively promising to me, but there is no implementation of that approach as of this writing. If you want to support finding a solution, please contribute to this email thread of join #debian-usrmerge on oftc. Helmut
Attachment:
ineffective_conflicts.yaml
Description: application/yaml