Hi Michael,
On Thu, Jul 15, 2021 at 12:22:59AM +0200, Michael Biebl wrote:
> You are right. Thinking more about this, splitting out libsystemd-shared as
> a Multi-Arch: same library will not help with
> SystemCallArchitectures=native, which is used by the services in
> systemd-{container,journal-remote,...}.
That is correct, but it actually goes beyond systemd-* using systemd.
Any other service can face the very same problem.
> So splitting out libsystemd-shared, while in theory a nice solution, is not
> the right one in this case. We really need to ensure that systemd and
> systemd-* are of of the same architecture.
We have two related issues at hand. One is the libsystemd-shared
architecture matching and the other is the SystemCallArchitectures
matching. You appear to imply that both issues need to be addressed by
one common solution. Sure that would be nice, but is it required? Maybe
these issues are not that related after all.
Let us for a moment assume that we could magically make
SystemCallArchitectures work by locking users to the same architecture
as systemd. That would be bad in terms for mixed multiarch systems and
cross grading, because you essentially lock all daemons to the same
architecture as systemd. You fix the problem, by removing flexibility.
I also proposed a solution here, which is avoiding
SystemCallArchitectures=native. Initially, that sounds like a
maintenance nightmare until you notice that it can be solved on a
technical level. We already have dh_installsystemd. How bad would it be
to have dh_installsystemd change .service files and automatically
replace =native with a concrete architecture (in arch:any packages
only)? systemd would no longer detect the architecture of services from
its own one but rather use the one documented by the package. The mixing
of architectures that our earlier solution broke would now partially
work. We'd fix one package and binNMU the pile.
So while these problems are related, I think that forcing the
architectures to equal is a suboptimal solution for
SystemCallArchitectures.
> I still think that my idea of having a ":arch" annotation as counterpart to
> ":any" would be the most elegant way to achieve this. But since this is only
> an idea and not implemented, it's not something I can make use of. Do you
> think there is a chance we could convince dpkg and apt maintainers to add
> support for that?
If you replace :arch with :$DEB_HOST_ARCH, it already works today with
apt and dpkg, but not dose. The question is not whether we can implement
that (it already is), but whether we want to endorse these semantics or
not.
> Alternatively, your idea of systemd-core/systemd got me thinking.
> While I don't like the prospect of moving all (conf)files and state from one
> package to another, maybe we can turn this idea around.
>
> We introduce an empty systemd-native package, which is
> Architecture:linux-any but *not* Multi-Arch: foreign/same/allowed.
>
> systemd and all systemd-* packages would depend on systemd-native.
> This would link the architecture of systemd and systemd-* together and
> ensure they are the same.
I think this technically works. We also have prior art for this. blas
temporarily added such a package as a measure to fix #760936.
> Would this work for your cross-compile use-case?
I don't think this would negatively affect cross compiling. It could
affect people who try to run mixed-architecture systems though.
Given Simon's and Guillem's replies, I presently favour fixing the NEW
processing to package the library separately and fix
SystemCallArchitectures using dh_installsystemd, because it is
technically sound and does not negatively impact multiarch use cases.
Should I file a bug about SystemCallArchitectures such that we can track
it somewhere?
Helmut
