On 11/1/19 3:16 AM, Russ Allbery wrote: > 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, It's well possible that I'm getting slowly convinced by your set or arguments. Thanks for taking the time to explain your view. Cheers, Thomas Goirand (zigo)
