Re: Need help with Multi-Arch in systemd

[Michael Biebl]

Hi Guillem,

thanks for your feedback

Am 09.07.21 um 13:46 schrieb Guillem Jover:

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.

The libsystemd-shared library is considered an implementation detail and indeed has no guaranteed backwards or forward compatibility. The soname is bumped when the first rc1 release is made (e.g v249-rc1 → libsystemd-shared-249.so) and there might even be incompatible changes between the rc1 and the final release.

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.

systemd-container (4 binaries in $PATH, 7 services, 11 total)
systemd-coredump (1 binary in $PATH, 1 service, 2 total)
systemd-journal-remote (3 services, 3 total)
systemd-timesyncd (1 service, 1 total)

(I'll exclude systemd-tests, as this is a special case)

This observation is correct I'd say. Currently we have the following split-off binary packages which ship binaries that link against libsystemd-shared: The main difference here, is that none of those binaries is really critical for the runtime of the system. An unbootable system though is one of the worst things that can happen. Which is why I'm really reluctant to split off libsystemd-shared from systemd and hopefully also explains why in general I'm not super keen on chopping up src:systemd unnecessarily.

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.

$ find . -name meson.build | xargs grep rpath | wc -l
123

A name-versioned package would certainly be better then an unversioned libsystemd-shared package. It still would make PID 1 a bit more brittle though (see e.g. my comment regard rc releases). It would also need patching of the build system, to override the rpath, which would have to be multi-arch aware. This would be a significant patch with a lot of ongoing churn and maintenance effort. I'm not sure if I'm willing or even able to do that.

Another solution might be to request upstream to stabilize this library?

The point of libsystemd-shared is to be an internal implementation detail where ABI can be broken. There are certainly no plans to change that upstream and I don't think I can convince upstream otherwise on this matter.

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?

So, option 4).


Regarding the numbers:

systemd-container (11 binaries)
Installed-Size: [-1278-] {+5644+}

systemd-coredump (2 binaries)
Installed-Size: [-276-] {+1106+}

systemd-journal-remote (3 binaries)
Installed-Size: [-336-] {+1218+}

systemd-timesyncd (1 binary)
Installed-Size: [-209-] {+595+}

I think the increase in size is significant.
More importantly, I'd need help maintaining this patch going forward







option 5)
do nothing?

I mean, we shipped the M-A: foreign notation for systemd since 2014.


Regards,
Michael

I tried that for v249. It's doable, but as this there no upstream support for that, it requires a patch which is significant and would require ongoing maintenance effort as well. I acknowledge, that option 2 and 3 makes Helmut's work on cross-building harder, although I think that option 3 would be preferrable to 2, as it as least leaves the door open for making cross-building possible. So, unless we get a :arch annotation that can be used for M-A:foreign packages, maybe the best option is If there is one bug report regarding such an architecture mismatch in 7 years, maybe the most pragmatic approach is to simply ignore it, given the downsides of the alternatives? I'm not sure what the best course of action is here.

OpenPGP_signature
Description: OpenPGP digital signature