Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie <s...@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. Namely: > 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). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
