Re: Pause /usr-merge moves
Hi developers,
On Fri, Dec 01, 2023 at 10:04:12PM +0100, Helmut Grohne wrote:
> 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.
I got more feedback mainly from David Kalnischkies and Enrico Zini this
time. Thank you for wrapping your head around this!
> 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.
David Kalnischkies made me aware that we need to treat unversioned
Conflicts separately from versioned Conflicts here. With unversioned
ones, we typically manage the provider of a virtual facility. The
barrier package approach can be used here, but it requires each provider
to have its own barrier package rather than one central barrier package.
Also when changing providers of a facility, apt will usually remove one
provider explicitly before installing another without the
--set-selections dance that triggers the problematic behaviour. I have
not seen any way of invoking apt yet that would cause the problematic
behaviour, but that can be due to me not trying hard enough.
For versioned conflicts (where the conflicted version generally is in
bookworm and not in trixie), a single central barrier package might do,
but we can also start with one and split it up later if providing
multiple barriers from the same binary package initially. For instance,
the files diverted by molly-guard would require a barrier package that
also handles bfh-container and progress-linux-container on one side and
systemd, finit, kexec-tools, runit and sysvinit on the other. Such
grouping can significantly reduce the number of barrier packages for the
versioned case without severely limiting the options to the solver.
> Another option is duplicating affected files (e.g. using hard links) in
> the data.tar and then restoring lost files during postinst.
I note that in case of systemd (and finit and runit), all of the
affected files are symbolic links, so we can pull this off without
actually changing data.tar and just restoring the links in postinst. We
wouldn't actually need that many backup copies. I'll look into drafting
a patch.
> Depending on what problem we are solving, we may also move to protective
> diversions (DEP17 M8).
If we have a choice between introducing a barrier package and protective
diversions, I think the protective diversions are the lesser evil. A big
chunk of the not-yet-conflicts can probably be done with protective
diversions instead. The thing that cannot be solved with protective
diversions is diverting an aliased location. We cannot fix diversions
with diversions unfortunately. Still that would lower the number
significantly.
It also is a little unclear how much effort we want to spend on avoiding
this kind of breakage. When using apt, we want things to work, but when
using dpkg directly and issuing dpkg --set-selections maybe that's used
rarely enough that we can point out the problems in release notes and
call it a day? In order to have apt not trigger this scenario, it seems
sufficient if molly-guard from sid were usable with (aliased)
systemd-sysv from bookworm (i.e. not having Breaks for bookworm's
systemd-sysv). Doing that allows apt to simply upgrade molly-guard
before systemd-sysv and then things would just work. You could still
reproduce the file loss if you poked hard enough, but we could call
those artificial cases than and ask people to reinstall affected
packages after having experienced the file loss. How do others feel
about reducing our support promise here?
The total number of cases is also still very much vague. Reasons:
* Unversioned conflicts incur a barrier package per provider while
versioned conflicts can be grouped. The grouping can be changed if we
use virtual barrier packages.
* We do not know in advance how many affected packages are restructured
and when they are, we may choose to mitigate those cases with
protective diversions rather than Conflicts.
I understand that this doesn't really answer Bastien's questions, but I
don't have better answers. At this time I'm looking more feedback as to
what our preferred trade-off is and reaching consensus about that
question. The list of issues (including trixie ones) was already
attached though.
Helmut
Reply to: