Re: Pause /usr-merge moves
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
>
Reply to: