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

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

I just want to subscribe with a very big +1 to what OdyX has said here:

Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]:
> (...)
> > 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 
> point.
> 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 
> namespace.
> 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 
> /bin/sysusers).
> 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.

/usr/bin/systemd-* is clearly implementation-specific. Now, if we are
to allow alternative implementations of /usr/bin/systemd-brewmycoffee,
we should first push to an alternative /usr/bin/brewmycoffee, get the
systemd maintainers to "subscribe" to it using our great alternatives
system, and provide our /usr/bin/open-brewmycoffee.

And I think that now, that not so many packages have yet adopted
systemd-derived facilities, is a great time to set this as a good

Attachment: signature.asc
Description: PGP signature

Reply to: