On Thu, 02 Jan 2020 at 09:03:24 -0500, Sam Hartman wrote:
> My understanding is that systemd's implementation of tmpfiles and
> sysusers works even while systemd is not pid 1.
> Why do we need multiple implementations for Debian ports where systemd
> runs?
I think this is partly down to whether the systemd maintainers (both
upstream and downstream) are willing to support this use, or whether
they would prefer non-systemd-booted systems to use a reimplementation
whose maintainers are responsible for supporting it. Do we know which
of those is true?
I seem to remember a systemd upstream developer being asked during
recent discussions whether they were willing to guarantee that
systemd-tmpfiles and systemd-sysusers will continue to work when used on
non-systemd-booted systems (not just sysvinit, but also chroots, Docker,
etc.), but I'm afraid I've lost track of what the answer was. The current
dh_installsystemd postinst fragments for tmpfiles.d are guarded by
[ -d /run/systemd ] so that they will be a no-op on non-systemd-booted
machines.
(I don't see any particular reason why those tools would be init-dependent,
though - they share systemd core code for utility stuff like configuration
file parsing, and I suspect that's all.)
If we want opentmpfiles and opensysusers to be available on only the
non-Linux-kernel ports, prototyping the packages on Linux + sysvinit
systems might also be the most pragmatic short-term way to get them
working well.
smcv
