On 1/29/20 11:34 AM, Raphael Hertzog wrote: > On Tue, 28 Jan 2020, Thomas Goirand wrote: >> This is exactly what should be avoided. It's perfectly fine to try to >> use opensysusers with systemd if one wants. In fact, that's exactly the >> best way we could do to be able to test it. Also, dpkg-divert is really >> ugly, and something you use as the last resort, when all other options >> have been exhausted. > > It's not that ugly if you consider that you are in an experimental phase > where you want to test opensysusers. > > Also you seem to imply that the common interface is the systemd-sysusers > binary. I don't think that this is necessarily the case. The common > interface is the file format. The name of the program creating the users > is not important as long as it's properly hooked in the packaging system > and boot sequence.
Hi Raphael, I'm replying to you, but it goes also for Phillip Kern too, which had a similar answer. My idea is to have a single entry point for programs to call the sysusers binary. If we collectively decide that it's going to be called /bin/foo, then by all means, let's do that. But I don't think it's reasonable to say it's going to be called /bin/systemd-bar, and nobody can take over this path. This is the wrong answer to the problem. I do agree that the data file is the interface, but can you predict *ALL* the cases where /bin/systemd-sysusers is called? As much as I understand, it could be called by: - something debhelper adds to postinst - something the maintainer adds manually to postinst - the init system itself And more disturbingly, it could be called by any program that just wants to add a user the same way one would just call useradd or adduser. The man page for systemd-sysusers even gives a very clear example: echo 'u radvd - "radvd daemon"' | \ systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf which clearly, looks like something someone would write in a shell script, manually calling /bin/systemd-sysusers, from anywhere, maybe even from a running program / daemon (I haven't seen any designed limitation, have you?). So I am in the opinion that "as long as it's properly hooked in the packaging system and boot sequence" simply doesn't work in this case, as systemd-sysusers could be called from virtually anywhere. As for the use of dpkg-divert, as you wrote above, it's ok for experimentation, but I do think it's making a disservice to our users to use that as the proper interface to implement. The update-alternatives has the very nice advantage that it clearly shows the current status of the system, and that it can be very easily tweaked, by hand or by some kind of automation. It's also super easy to go from one state of the system to another, compared to reinstalling / uninstalling a package. Cheers, Thomas Goirand (zigo)
