Re: Need help with Multi-Arch in systemd
Hi Michael,
thanks for reaching out!
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> a couple of days ago, the following bug report was filed against systemd
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
Imo, this is bug should be serious. In essence, it is a missing
dependency and we track missing dependencies as serious.
At the same time, I find it so unlikely to happen in practice combined
with the difficulty of finding a good solution that I'd propose
bullseye-ignore.
> Asking on #debian-systemd, Marco d'Itri suggested, that we move
> libsystemd-shared into a separate binary package. This would only help, if
> we moved libsystemd-shared into a Multi-Arch location (which means, we'd
> have to carry a patch against upstream). It would also mean, that on every
> new upstream release, systemd would have to go through NEW.
> So I'm not very keen on doing that.
I concur with Marco here and I argue that splitting the library is my
preferred solution. I confirm that you'd need to move the library for
this to work. For the other points I do not follow. I think it would be
ok to move the library using code inside debian/. Is there any reason
why you ruled out that option?
I also disagree with the need to go through NEW more than once. The new
package could quite simply be named libsystemd-private and lack a
.symbols and .shlibs file. Internal users would always use (=
${binary:Version}) anyway. The package description would declare that
any external dependency on libsystemd-private is a bug. Prior art:
libbinutils/binutils-dev.
One could argue that packaging a shared library like that is a policy
violation. If that is the case, then the current bundling is a policy
violation as well. So meh. It really sounds like a fair compromise to
me.
I am actually wondering now whether we should have a separate archive
section for "private" packages. I would define it as follows:
A private package is an implementation detail used by a single source.
Binary packages built from a one source package must not depend on
private packages built from another. Dependencies on private packages
should use tight version requirements (e.g. (= ${binary:Version}).
I suppose that a number of *-common and *-data packages as well as
gcc-N-base could be moved to such a section. User interfaces for package
managers could hide private packages by default.
Regardless of whether we add an archive section, lintian could carry a
list of private packages and enforce the no-dependency rule.
> 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.
> Option 3 is something I came up with after reading the Multi-Arch related
> wiki pages:
> https://salsa.debian.org/systemd-team/systemd/-/commit/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6
> It would mean marking systemd as Multi-Arch: allowed. And packages that only
> use architecture interfaces of systemd would have to use the :any
> annotation.
Yeah, this technically works, but it causes a lot of maintenance effort,
because you get to hunt down every single systemd dependency in the
archive for years. I think our time is worth more than the cost of
introducing a new binary package into the archive.
> I would appreciate feedback, if option 3 is proper solution or not, or if
> there are other, better alternatives. If we go with option 3, should I
> inform all rdeps of systemd to update their dependency accordingly, i.e. do
> a MBF?
The problem I see here is less with annotating all deps once. It is more
the constant effort it incurs. It is not obvious that you should
annotate your systemd dependency :any. People will forget that when
adding systemd dependencies. What I take issue with is the permanent
cost that we keep in the long run.
Hope this helps
Helmut
Reply to: