On Fri, 2021-07-09 at 12:29:19 +0200, Michael Biebl wrote: > Am 09.07.2021 um 11:37 schrieb Timo Röhling: > > * Michael Biebl <bi...@debian.org> [2021-07-09 11:01]: > > > Splitting out libsystemd-shared (once) will make PID1 very brittle. > > > It can lead to situations where old systemd + new libsystemd-private > > > is installed. If the installation is aborted at this point, you have > > > an unbootable system.
> > Helmut suggested a tightly versioned dependency, so such a state > > would never be consistent. > That tightly versioned dependency doesn't help unfortunately. There is still > a time window between the new libsystemd-shared and the new systemd being > unpacked. If the private library has no backwards or forward compatibility (due to the SONAME used) the time window where the library does not match the expectations of the stuff linked to it might indeed be too big. But the reported bug is just a symptom of a bigger issue. This problem already exists for any of the other binary packages built against this private shared library, there's a time-window where they will not work if the installation gets interrupted or fails, compared with public shared libraries. This implies to me the correct solution is a name-versioned package, even though that seems cumbersome given our current archive handling practices this is IMO the only correct solution. The alternative of using Multi-Arch:allowed is a workaround for this packaging problem. Another solution might be to request upstream to stabilize this library? Yet another solution, which seems suboptimal, might be to statically link it, but the shared library seems rather big, but perhaps if the programs linked only use parts of it, that might not be too bad? Thanks, Guillem
