Le vendredi 1 décembre 2023, 21:04:12 UTC Helmut Grohne a écrit : > 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.
Could we have a list of trixie affected ? > > 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. Why not creating per package a barrier package ? > > 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 >
