Bug#947847: please install systemd-sysusers using update-alternatives

[Thomas Goirand <zigo@debian.org>]

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)