Re: Bug#886238: Please introduce official nosystemd build profile
On Thu, 04 Jan 2018 at 23:01:07 +0100, Svante Signell wrote:
> What about creating a linux-nosystemd architecture, e.g.
> dbus-1.12.2/debian/control
> Build-Depends:
> libsystemd-dev [linux-any !linux-nosystemd]
> etc.
We've never applied such drastic measures for other small libraries that
enable optional features, even when the size of Debian was a much larger
proportion of typical storage media than it is now.
dbus is a nice example so I'll stick with it. It also depends on
libapparmor and libselinux, and it's literally impossible[1] for both of
those libraries to be useful on the same Debian machine; but dbus-daemon
depends on them anyway, because the benefit for people who use the
appropriate LSM is significant, and the cost to everyone else is
trivially small.
libsystemd is no different. It's a library that is relevant on some
system configurations, and does basically nothing on others. Debian is
a binary distribution, so we enable the majority of optional features
at build-time to maximize the applicability of our binaries.
If you want proponents of continued support for non-systemd init to be
taken seriously, I would recommend treating libsystemd as part of the
price you pay for using generic binaries that came from a general-purpose
distribution's buildd, just like libapparmor (if you don't use AppArmor)
and libselinux (if you don't use SELinux). I'm sure you wouldn't want
to create the (hopefully false) impression that opposition to systemd
is based on superficial appearances more than on technical considerations.
Here are some examples of more constructive/less negative ways that
Debian contributors could improve the state of traditional init systems,
if that's something they are interested in putting work into:
* maintain init systems (I notice initscripts currently has a
release-critical bug open)
* evaluate alternatives to systemd-logind that achieve the same goals
without requiring systemd as pid 1 (elogind looks promising)
I'm trying hard to be even-handed, assume good faith, and not get into
an "us vs. them" mindset, but every time I find myself reading a thread
like this, that gets a bit harder to do. If threads like this frustrate
enough people, there's a risk that they'll tilt the project consensus
towards considering the cost of choice of init system to exceed the
benefit, and dropping support for non-systemd inits altogether, which
is presumably not what you want to happen.
smcv
[1] until "LSM stacking" is implemented in the kernel, which I hear will
happen any year now
Reply to: