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