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
