Re: Integration with systemd
Thomas Goirand <zigo@debian.org> writes:
> ...the bigger question is: why systemd-sysusers is part of systemd, and
> not a standalone thing, which we could make an essential package. If we
> want it to be part of a package standard toolkit, it means systemd
> becomes an essential package, which isn't really what we want (we don't
> need an init system in a chroot, as you know). For that reason alone,
> it's probably a bad idea to recommend systemd-sysusers everywhere.
I don't claim to know the full answer to this question, but if I had to
guess, it's not particularly exciting: (a) the people who wrote it decided
to include it in the systemd project for watever reason, probably because
it was convenient and they were systemd developers, and (b) in the absence
of any particular reason to break parts of systemd off into separate
packages, the systemd maintainers have quite rationally minimized their
work and packaging complexity.
Note that upstream is probably not interested in promising
systemd-sysusers will always run under non-systemd init systems. I don't
know if there's any current or future reason why it wouldn't (maybe the %b
or %m specifiers use some systemd library, although maybe they don't; I
have done precisely zero investigation), but I doubt they'd make such a
guarantee. Folks may with some reason think they're wrong for not caring
about that, but they're of course entitled to care and not care about
whatever they want. It therefore might be as simple as just making a new
binary package, or it might not, and even if it is now, it might not
always be.
On my side, what I find interesting is the declarative syntax and
therefore the configuration files. I don't really care if we use the
systemd-sysusers program or something else (although obviously it's easier
to use the thing that's already written and that someone else is
maintaining for us). I do (mildly) care that we use the same syntax and
features as systemd because I think there's value in convergence between
Debian, Red Hat, and other distributions. The divergence between Debian
and Red Hat and the correspondingly large differences in how you
administered systems used to be really irritating; reducing gratuitous
difference where neither approach is better, just different ways of doing
the same thing, is a feature to me.
What I want out of a GR is to decide the deeper meta question of just how
much effort the project wants to put into problems like this. The
*easiest* approach for Debian (assuming you agree with me about moving to
a declarative syntax) would be to just say sysusers.d is now supported and
preferred (except possibly in edge cases where it won't work; places where
adduser is a pre-dependency will require special handling), and use the
existing implementation and move on. This would obviously break sysvinit
until someone wrote an equivalent program.
A more moderate approach would be to say that once that alternative
implementation was written, or alternately we've established that
systemd-sysuers will work on sysvinit systems and we're at least somewhat
committed to keeping it that way or writing something new if it doesn't,
*then* we can start using sysusers.d, but until then it's not allowed (and
there's a bug in the tomcat9 package).
Yet another option would be to say that we like adduser and maintainers
are still required to use adduser, and systemd-sysusers is not supported
and not allowed.
Of course, we shouldn't use a GR to decide this for systemd-sysusers
specifically. That's way too detailed for a GR. But the point of many of
us in the thread is that pretty much exactly this same set of alternatives
are present for something like ten different facilities (if not more). I
don't think we actually want to make separate conflicting decisions about
each one; I'm pretty sure that there is a general *philosophy* that we
want to apply here, which is roughly somewhere on a spectrum between
"let's start using systemd native services whenever they're available,
stable, and solve some Debian problem, regardless of whether that breaks
sysvinit" to "all this systemd stuff is unappealing and inferior to what
we can do ourselves; let's decide to not use it and stick with our
facilities."
(Note that there is another option, which is "let's go all in on systemd
and use the systemd-native way of doing *everything*, right away." I'm
fairly sure that at most a tiny minority of folks in Debian want to do
that; I'm pretty sure not even the systemd maintainers want that. Rather,
the most aggressive option I expect anyone to support in significant
numbers still implies some sort of Policy vetting of a new facility to
make sure it solves a real problem and that we've given some thought to
how to integrate with it before we just start using it. For instance, we
would want to make sure that systemd-sysusers honors our system UID ranges
and naming rules.)
I truly don't know where on that spectrum the *project* wants to be. I
know where a lot of individual vocal members of the project want to be,
but that's not at all the same thing.
One advantage of a GR is that you can express an opinion without being
required to dig through and interact with large and somewhat contentious
debian-devel threads.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: