Re: Need help with Multi-Arch in systemd
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 <biebl@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
Reply to: