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

[Michael Biebl]

On Thu, 1 Jul 2021 10:33:01 -0600 dann frazier <da...@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

https://lists.debian.org/debian-devel/2021/07/msg00070.html




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






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





b/
+ very simple solution

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

c/


- needs a round trip through NEW on each new upstream release.

@bluca, do you have any idea if this would be feasible in any way?



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









Regards,
Michael

[1] I do have such a patch ready and can try to submit that upstream

I've been thinking about this quite a bit, and afaics we have the following 4 options after having discussed this on a/ keep the status quo, i.e. continue to ship libsystemd-shared (and as of v251, libsystemd-core) in the main 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 + 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 + less chance of breaking PID1 as we can install old and new libsystemd-shared in parallel - 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 - 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). - 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.

OpenPGP_signature
Description: OpenPGP digital signature