Bug#947847: please install systemd-sysusers using update-alternatives
On Mon, 27 Jan 2020 at 11:18:53 +0100, Thomas Goirand wrote:
> you don't seem to agree that it'd be ok for one to use
> opensysuser instead of the systemd implementation if systemd is running.
> I do not agree with this, and I believe it is up to the users to decide
> what to do, even if we, as an operating system, must provide sensible
> defaults
I hope everyone involved can agree that:
- we should provide choices where their benefit exceeds their cost,
because more choice results in a more widely applicable system;
- we should not provide choices where their cost exceeds their benefit,
because more guarantees result in a more robust system
(By "cost" I mean developer time spent, avoidable bugs caused, etc. -
not money.)
To take some clear examples: at one end of the scale, we provide a way to
configure per-system whether /usr/bin/editor is emacs or vi or whatever,
because that's primarily about subjective, personal UI preference. At the
other end of the scale, we *don't* provide a way to configure per-system
whether /bin/tar is GNU or BSD tar: we want packages that run tar to be
able to make the simplifying assumption that on any Debian system, it's
going to be GNU tar, and we do not want to deal with bug reports from
users who have switched to an unexpected tar implementation.
So this is at least partially a question of whether making
opensysusers vs. systemd-sysusers easily sysadmin-configurable has a
cost greater or less than its benefit, or to put it another way, where
it falls on a scale between /usr/bin/editor and /bin/tar.
With that in mind: Thomas, or anyone else asking for this change, what
benefits do you expect users of Debian to obtain from being able to
install both opensysusers' implementation of the sysusers.d interface
and systemd's, and choose which one is invoked from the boot procedure
and packages' postinsts via configuration, as opposed to via package
installation/removal?
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)
- Linux systems booted using systemd
It might be helpful to consider which benefits apply to which of these
categories.
For example, the first category certainly benefits from opensysusers
*existing*, but does not directly benefit from co-installability or from
having a choice, because there is no such choice: systemd's -sysusers
is not available there, so using something non-systemd is the only option.
I think we have a fairly good picture of the costs that would be
incurred from using alternatives: more interacting code paths to test,
potentially more configurations that are technically possible but are
not considered supported, and packages with "Depends: systemd (>= 321)"
(or indeed systemd itself, in the case of systems using it to boot)
not being able to rely on having access to all systemd 321 features,
which doesn't seem like a least-astonishment situation to be in. However,
Michael, or anyone else opposing this change: if you have anything to
add to those, please do.
Thanks,
smcv
Reply to: