Re: Integration with systemd
On Thu, 31 Oct 2019 at 17:51:28 -0700, Russ Allbery wrote:
> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users
I have been tempted to write a small reimplementation of systemd-sysusers
suitable for init-less containers and sysvinit systems, so that we can
rely on its declarative syntax even on non-systemd systems - even though
I use systemd myself and am happy with it as my init system, so it's
entirely possible that I would never *use* the reimplementation.
I've vaguely considered the same thing for tmpfiles.d, although a full
reimplementation of tmpfiles.d is somewhat more difficult because it's
more featureful.
The major problem with either of these is that, at the moment, packages
that ship a sysusers.d or tmpfiles.d fragment can assume that the consumer
of those fragments has the complete feature-set of systemd (at least the
version in stable), whereas if there was a reimplementation, we'd need to
have an answer for packages that use features that are supported by
systemd's reference implementation but not yet supported by the
reimplementation.
> And presumably you would instead propose banning use of systemd-sysusers
> and sysusers.d and requiring continuing to use adduser from maintainer
> scripts as we currently do. I would object because to me that's obviously
> inferior to a declarative syntax.
Whether declarative or imperative, it's also Debian-specific - which
I think is not *necessarily* a problem, but runs a risk of becoming an
instance of this frequent anti-pattern:
* we identify a problem that needs some sort of system-integration glue
* we solve it in a Debian-specific way (either intentionally or
unintentionally)
* other distributions later realise they have the same problem
* they solve it in upstream projects or in a cross-distro way
* often, we end up dropping our solution and using theirs - even if ours
had significant advantages over theirs! - because theirs has wider
upstream support, or because it keeps up with new requirements where
ours does not
The Debian menu being replaced by .desktop files is a classic example.
It seems to be somewhat common that the Debian-specific solution
is more versatile - imperative maintainer scripts vs. declarative
configuration, or /etc/X11/Xsession.d vs. environment.d(5) - which makes
it flexible, but hard to reason about and hard to change or replace,
because packages that integrate with the Debian-specific solution could
be doing *anything*. Xsession.d has this particularly badly, because
it's a mixture of setting environment variables (which should ideally be
inherited by all session services) and starting session services (which
obviously can't inherit environment variables that haven't been set yet),
making it difficult to sequence the script fragments correctly.
smcv
Reply to: