[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#947847: please install systemd-sysusers using update-alternatives

Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie <smcv@debian.org>:
> [...]
> I think there are three categories of systems that it might make sense
> to consider separately here. In ascending order of "amount of systemd":
> - non-Linux ports to which systemd does not intend to be portable (and
>   I think we can treat non-systemd-by-policy derivatives like Devuan as
>   basically equivalent to these), where the systemd implementation of
>   -sysusers simply does not exist
> - Linux systems not booted with systemd
>   (either no init system at all, like a typical schroot or Docker
>   container, or a non-systemd init system like sysvinit)
> [...]

For this particular case it's probably worthwhile to also consider
Zbigniew Jędrzejewski-Szmek's comment on debian-devel a while back,
where they extended systemd's interface stability and compatibility
promise based on our discussions back then.

> Independent operation of a bunch of
> programs is now explicitly covered, and the stability promise
> has been extended to more interfaces.

>From https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs
systemd-sysusers and tmpfiles are covered by this promise, as well as
a few other utilities.
So, especially for container usecases it may actually be reasonable
for the systemd maintainers to make those utilities available in a
separate package to be installed without the daemon components. That
way they would be readily available and working even on systems where
systemd isn't PID1 (of course, the daemons should also be inert until
an alternative init system starts to parse systemd service files, so
at the moment even installing the systemd package itself for these
binaries is safe).


I welcome VSRE emails. See http://vsre.info/

Reply to: