Bug#990547: libsystemd-shared broken in Multi-Arch

[Michael Biebl]

On Thu, 1 Jul 2021 10:33:01 -0600 dann frazier <dannf at dannf.org> wrote:
> Source: systemd
> Version: 247.3-5
> 
> I noticed that systemd-machined was failing to start on an arm64
> box. This box had armhf enabled, and turns out systemd had been
> cross-graded over to systemd:armhf[*]. It still had
> systemd-container:arm64 installed, so now I had an arm64
> /lib/systemd/systemd-machine, but an armhf
> /lib/systemd/libsystemd-shared-244.so.
> 
> libsystemd-shared-244.so is from the systemd package. Since systemd is
> marked Multi-Arch: foreign, systemd:armhf was able to incorrectly
> satisfy systemd-container:arm64's dependency on systemd.
> 
> [*] kudos to Multi-Arch that I simply hadn't noticed
> 
> 


I've been thinking about this quite a bit, and afaics we have the 
following 4 options after having discussed this on
https://lists.debian.org/debian-devel/2021/07/msg00070.html


a/ keep the status quo, i.e. continue to ship libsystemd-shared (and as 
of v251, libsystemd-core) in the main systemd package

b/ drop the Multi-Arch: foreign notation from the systemd package

c/ split /lib/systemd/libsystemd-{shared,core}-{ver}.so into a separate 
binary package named libsystemd-shared-{ver}

d/ split /lib/systemd/libsystemd-{shared,core}-{ver}.so into a separate 
binary package named libsystemd-shared


All the options have pros and cons. I'll try to list them as I see them.
Feel free to correct/amend them.

a/
+ least amount of work
+ the main /bin/systemd binary links against 
libsystemd-{shared,core}-$ver.so. There is no risk of them getting out 
of sync.


- mixing say systemd-container:i386  with systemd:amd64 leads to a 
broken systemd-container installation (basically what this bug report is 
about). This affects at least systemd-{container, oomd, timesyncd}. More 
is to come, as we intend to split src:systemd further

b/
+ very simple solution

- disallows many interesting use cases and e.g. makes Helmut unhappy.

c/
+ less chance of breaking PID1 as we can install old and new 
libsystemd-shared in parallel

- needs a round trip through NEW on each new upstream release.
- constant churn regarding packaging, as we need to update at least 
debian/control and debian/libsystemd-shared-$ver.install
- makes upstream-ci really awkward. atm we have the upstream-ci branch 
which is used among the main branch and in systemd-stable.
I don't see how we could continue to use a single upstream-ci branch for 
different systemd versions
@bluca, do you have any idea if this would be feasible in any way?
- needs a patch to src:systemd to move libsystemd-{shared,core} to a 
multi-arch path. If we can't get that accepted upstream, it would be a 
maintenance nightmare [1]
- unstable users will accumulate old libsystemd-shared-$ver packages 
which they need to uninstall again (e.g. via apt autoremove).


d/
+ upstream-ci could continue to work as-is
+ no constant NEW processing required

- makes PID1 more brittle, as the time window increases where 
libsystemd-{shared,core}-$ver.so and /bin/systemd could get out of sync.


Factoring this all in, I don't think c/ is really a workable solution, 
so my own preference would be
d > a = b > c, even if that means on compromising on the robustness of 
PID1. The only other alternative I see is to go with b/, i.e. drop the 
idea of Multi-Arch.

I do have code to implement d/, but before I try to engage with upstream 
here, I'd welcome your feedback.


Regards,
Michael

[1] I do have such a patch ready and can try to submit that upstream
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220530/3ab5fd0d/attachment.sig>