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 practice.
Attachment:
signature.asc
Description: PGP signature