[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.

Only words, I know, but let's try to answer technical points, not address 
people. "Talk to the space, not to individuals"
> 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.

Software installed as /bin/systemd-* , created within the systemd project, to 
fulfill systemd's view of the world, takes a reasonable hit on the binaries' 
namespace: "systemd-*". Really, we should be thankful that the systemd project 
actually started using /bin/systemd-sysusers and not just /bin/sysusers. To 
extend on this, I think it's obvious that what the "systemd-sysusers" binary 
name _says_ really is "this is a systemd-specific utility".

I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should 
be allowed to provide an alternative to /usr/sbin/cupsd.

Let's see if I understand what you want correctly; you want Debian to allow 
replacing systemd-specific software with alternatives, right? I'm sorry, but 
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared 
outside of the systemd repository, I think it's fair to say (because of the 
binary's name) that they were knowingly using a systemd-specific piece of 
software (and hence, have correctly added a "{Pre-,}Depends: systemd".

Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without 
systemd, or on a host booted with a different init system; I'm only saying 
that usages of systemd-sysusers must have appeared with full knowledge of 
using the systemd-sysusers binary from the systemd project.

> 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.

That's exactly the point: if it's so good that it has become used in many 
places, changing the binary behind the scenes is clearly premature at this 

If I reformulate what it seems to me you're asking, it comes accross to me as 
"/bin/systemd-sysusers comes from systemd and it should be possible to have a 
system without systemd installed, therefore please force the systemd 
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".

My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with 
a systemd-* name and I don't think it's reasonable to ask (or force) the 
systemd maintainers to allow "their" interface to be implemented by other 
software projects. Afterall, they came with the idea first, in their 

That said, taking a step back and looking at the larger picture, if what you 
wish is a Debian in which one can pick their preferred sysusers' 
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the 
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to 

With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard" 
interface instead. We have this for 'httpd', 'default-mta', what about having 
a virtual 'sysusers' ?

All-in-all, I think the question you're asking is misguided: it's not because 
we technically _can_ allow any /bin/systemd-* to be provided by another 
implementation, that we should (actually, I think we should clearly _not_). 
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing 
implementation is better (faster, less systemd, etc); there are various ways 
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or 
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried 
talking to maintainers using /bin/systemd-sysusers to see if they would like 
to swap to it? It's not like having two competing implementations causes much 
harm here.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: