Thomas Goirand <z...@debian.org> writes: > IMO, this type of decision should go in the policy, case by case, and > I'm not sure a GR is the solution: it's going to be a generic "use all > of systemd" vs a "be careful to use only things implemented elsewhere". > I don't think this works, as often, there is maybe a middle ground > "well, it depends on the situation". For the systemd-sysusers in > tomcat9, probably best would have been to keep thinks as they were > rather than using an implementation that only has the side effect as to > get locked-in, especially when it's easy to avoid the problem. For other > cases, maybe it's nice to be able to use systemd-only features, and here > I'm thinking namely about cgroup stuff, for example.
So, let's explore this "Policy on a case-by-case basis" approach. I think we should adopt sysusers.d fragments as the preferred mechanism for creating system users (with some rules, such as a standard for how to name the users and a requirement that the UID be specified as - unless one goes through the normal base-passwd registration process). It supports a declarative syntax, doesn't require putting runes of code into a shell script, moves us farther down the path towards reducing us of maintainer scripts for most packages, and avoids the whole dependency and pre-dependency mess with adduser that took forever to sort out. The syntax for sysusers.d is straighforward to parse, and support for non-systemd init systems via a trigger or boot-time script (or both) via adduser could be easily written, hiding the distinction between init systems. So I should propose putting that into Policy, right? Presumably you would object. 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. I've been beating the drum for declarative syntax to replace maintainer scripts in Debian since before systemd existed, and I personally don't care whether systemd happens to be the project that came up with a good facility or not. If I see a good opportunity for moving to declarative syntax, I'll support it. So now neither of our proposals has consensus, and Policy continues to be somewhat ambiguous about systemd-sysusers. (Policy currently says, in kind of a weird place, that using adduser is a "should," which makes it a non-RC bug to not do so, but shoulds are often interpreted by the project to imply a certain amount of maintainer discretion.) Now what? This is why I don't think your strategy of avoiding a GR and just having Policy sort this out somehow doesn't work. (Also, just to head this off in advance in case anyone wants to argue it, I personally am dead-set against a position that says "if we can't get consensus, we require everyone to do what we've always done." I think that's a recipe for endless sniping, hard feelings, and eventual obsolescence. Debian is too large now to be able to do literally *everything* by consensus; there are some things where we'll always find someone who objects to every course of action.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>