Hi Michael,
in your other mail, you gave a very good reason for keeping the systemd
binary and libsystemd-shared.so in the same binary package. That
improves my understanding of why you favour option 3.
On Fri, Jul 09, 2021 at 11:31:15AM +0200, Michael Biebl wrote:
> Am 09.07.21 um 10:28 schrieb Helmut Grohne:
> >
> > On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
>
> > > Option 2 would be to drop Multi-Arch: foreign from systemd. This would
> > > mean,
> > > that packages like libpam-systemd/libnss-systemd can no longer be
> > > installed
> > > for a foreign architecture (even though those modules only use
> > > architecture
> > > independent interfaces of systemd).
> >
> > That would break a pile of use cases and cause a lot of pain downstream.
> > Please don't.
>
> Can you iterate on that a bit? I was looking for use cases, but couldn't
> come up with them.
I guess you already know what comes next: cross building. 4700 packages
include systemd in their Build-Depends. Many of them would immediately
become cross bd-uninstallable. For others, the installation set would be
satisfied with a foreign systemd, which would quite simply fail to work.
Any kind of mixed-arch system where you want to install a daemon that
depends on systemd for a foreign architecture would also be affected.
Someone attempting to do so might accidentally cross grade systemd in
doing so.
> As said, option 1 is not something I really consider a viable option for the
> aforementioned reasons.
>From my pov, the only reason left against 1 is partial upgrades breaking
the installation. It's a strong one anyhow.
> So, packages need to decide whether they use architecture independent
> interfaces of systemd or not and annotate it accordingly. But they only need
> to do that once. Isn't this the same as with any python, ruby or perl
> dependency?
Yes. For perl and python, we haven't even annotated half of the relevant
Depends with :any yet. Experience tells, the annotation is not gonna
happen.
> Maybe having something like the inverse of M-A: allowed would be useful?
> Instead of having packages explicitly opt-in via a :any annotation, they can
> opt out and request the same architecture even if a package is marked as
> M-A: foreign?
> So the select few cases which use an architecture dependent interface of
> M-A: foreign package would use something like pkg:arch ?
If I were to design Multi-Arch today, I would likely agree. The
transition cost to get there seems prohibitively high though. I've tried
hard to change the spec and I did not succeed (on the Multi-Arch
interpreter problem). Yet, we devised a workaround for that issue. So
you made me thinking, can we somehow implement this with our current
spec? The most important requirements seem to be:
* libsystemd-shared.so and /sbin/systemd need to reside in the same
binary package.
* It shall be possible to depend on libsystemd-shared.so for a
particular architecture.
* A dependency on "systemd" should request a native systemd.
Now let's do something stupid. Rename systemd to systemd-core (taking
all files with it, please refrain from discussing the name unless you
seriously consider doing this). Mark it Multi-Arch: allowed. Add a new,
empty binary package systemd. It is Multi-Arch: foreign and depends on
systemd-core:any. This approach would technically satisfy all three
requirements, but it feels a little crazy to me.
Another possibility (kudos to David Kalnischkies) would be exploiting
something I might call a loophole in the Multi-Arch spec. While we don't
currently use arch-qualified dependencies in the archive, the spec
considers them and dpkg and apt support them (somewhat). So in theory,
we could say that systemd-container Depends: systemd:${DEB_HOST_ARCH}.
I'm not sure whether all resolvers agree on this, but I'd expect this
dependency to pull the right instance (despite being marked Multi-Arch:
foreign). Before jumping onto this, please consider David's warning:
here be dragons.
I'm relaying another question from David: Assuming we'd solve the
libsystemd-shared.so issue, would systemd-container:arch1 actually work
with systemd:arch2 or are there more aspects where the same architecture
is assumed?
As we already are going crazy in the search for solutions to this, let
me propose a scary one. I have no idea whether this works in practice.
Split out libsystemd-shared.so into systemd-private like before, but at
the same time ship it in systemd. That causes a conflict of course, so
systemd-private Conflicts: systemd:${DEB_HOST_ARCH} and systemd
Conflicts: systemd-private:${DEB_HOST_ARCH} as well as Provides:
systemd-private:${DEB_HOST_ARCH}. These Conflicts must be arch-qualified
as otherwise they're interpreted as any instance. We already have
arch-qualified Conflicts in the archive, so this aspect likely works.
I'm less sure about arch-qualified Provides though. In any case, the
(common) native case would be systemd without systemd-private and thus
harmless. Please consider this a crazy thought experiment for now.
And I fear we have another related issue that we swept under the carpet
thus far. man systemd.exec explains SystemCallArchitectures=native.
Thus we should consider it part of the API that systemd provides to
client packages. Of course what "native" means here depends on the
architecture of the systemd binary package. If I were to package a
daemon that uses SystemCallArchitectures=native and depend on systemd, I
could end up in a situation where my daemon architecture differs from
systemd's architecture (due to the present M-A:foreign). Once starting
the daemon, systemd would block all syscalls as they all use the wrong
architecture. So any package that uses SystemCallArchitectures=native
technically should depend on a systemd of the same architecture.
However, a better solution would be to not use
SystemCallArchitectures=native in binary packages at all and spell out
the architecture of the relevant binary package instead. It's a bit
annoying to do so for maintainers as upstreams will quite simply use
native as a value.
Looks like this leaves us between a rock and a hard place. None of the
options seems particularly attractive to me at this point.
Helmut
