Thomas Goirand <z...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
