On Thu, 1 Jul 2021 10:33:01 -0600 dann frazier 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
OpenPGP_signature
Description: OpenPGP digital signature
