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
