Bug#947847: please install systemd-sysusers using update-alternatives
Hi Didier!
Thanks for taking the time to reply.
On 1/29/20 4:31 PM, Didier 'OdyX' Raboud wrote:
> 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".
They probably should be thanks to save the namespace, however, they
shouldn't be for pushing for bundling many different things in a single
software.
Let's say I was proposing an alternative implementation of
/usr/sbin/adduser (note that it doesn't have a software name in its
path...), would you allow it? Hopefully yes, if it had the same
functionalities, plus some other properties and improvement (like not
being written in perl... :) (just trolling here... hopefully we can have
fun in this discussion? :)).
Why is it controversial here? Maybe because upstream decided to bundle
it together with many unrelated components, as I wrote above, and prefix
the binary file name with the "systemd-" name, to give the impression
that it feels "integrated". Hopefully, you'll be able to enlighten me if
I forgot something else! :)
Some of us have complained about the non-modularity of systemd. My idea
was to prove them wrong, and that we can replace some of the components
that aren't that tightly integrated. It feels like upstream also
declares systemd-sysusers as an independent component, and kind of agree
with me on this specific point.
> Let's see if I understand what you want correctly; you want Debian to allow
> replacing systemd-specific software with alternatives, right?
It only your own opinion that systemd-sysusers is systemd specific. My
view is that what it does isn't more specific to systemd than
/usr/sbin/useradd, and that in the first place, it should have *never*
been part of a single systemd project. That's truth for many other
components of systemd, but let's not discuss this (it's out of scope).
Now that some are proposing that sysusers becomes a accepted Debian
interface, it becomes increasingly important that it becomes independent
from any other component of the system, and that it can be replaced or
reimplemented in a different way. Otherwise, maintainers scripts will
increasingly use it, and we become effectively locked-in, married
forever with systemd.
> 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.
I am contesting this.
It's bundled with systemd, yes. It's pre-fixed with the word "systemd-"
in its binary name, yes. The idea of the static sysusers data file comes
from systemd, yes. But it stops here.
Its core functionality isn't systemd specific. We've been adding systemd
users in maintainer scripts for decades, a long time before we even knew
the word "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)
The binary name is precisely a distraction which you should try to
ignore, because it is very misleading.
> that they were knowingly using a systemd-specific piece of
> software (and hence, have correctly added a "{Pre-,}Depends: systemd".
That is exactly what I would like to avoid. Hopefully, we will be able
to have:
{Pre-,}Depends: systemd-sysusers | opensysusers
or even:
{Pre-,}Depends: sysusers
if we get into the virtual package thing... And probably we should!
(maybe we can discuss this after this first discussion is done)
> 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".
I don't like *at all* the way you are reformulating, and that's not
really what I'm asking for. So please allow me reject the way you are
putting things, and let me phrase it my way.
I'm simply asking *Debian* (not systemd maintainers) to allow multiple
implementations of the same functionality (ie: adding users using a data
file format, which happens to have been invented by the systemd project).
To be able to allow another implementation to exist in Debian (which
happen to work anywhere, even without systemd, that's truth, but that's
not the only property of opensysusers), and a way in Debian so we can
standardize on.
This goes beyond the "I want to use sysusers in non-systemd setups". I
also want to be able to use opensysusers when I run systemd. In fact,
that's how I would like *my* own laptop / servers to run.
Anyway, there's a few ways to make this work, and both things to cohexist.
1/ Having a systemd-sysuser package that can be replaced by opensysuser
would work, and there is #946456 that is open for that, but currently,
it is unclear to me what Michael Biebl decision is about it.
2/ Standardize on /bin/sysusers as *the* interface everyone *must* use,
and use update-alternatives to make it point to either
/bin/systemd-sysusers or /bin/opensysusers-sysusers (or something
similar, you get the point), then declare the use of
/bin/systemd-sysusers a serious violation of the Debian policy and write
a lintian check for it.
3/ Stop being distracted by the fact the file is prefixed with
"systemd-" and allow anyone else to re-implement it using the
update-alternatives facility.
My order or preference is: 3, 2 then 1. The reasoning is that 3. is the
least amount of effort, project wide. 2 is the 2nd choice, because
probably the most elegant way, however, systemd will need to be patched
to allow using opensysusers at boot time if the user decides to. 1. is
annoying because to switch, one needs to run apt / dpkg.
Now, after reading what you wrote below, probably we should focus on 2/.
> My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with
> a systemd-* name
The binary name is very deceptive and annoying. I wished it was packaged
and maintained separately, because it has very little to do with an init
system. Please let's not use this as a point of argumentation.
> 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.
If I push your reasoning to the end, if systemd comes with any idea
first, and prefix the idea with their namespace, this means nobody has
the rights to provide an alternative. What you are describing feels even
worse than then patent system!
> 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).
Yeah, I'm very much ok with this solution. This is probably the most
elegant way, though it would work only if:
1/ We set in the stones of the Debian policy that everyone *must* use
/bin/sysusers, and *never* /bin/foo-sysusers directly.
2/ Systemd maintainers do patch systemd itself so that it uses
/bin/sysusers and not /bin/systemd-sysusers, so that *any*
implementation can be in use, depending on the user's choice.
> 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' ?
Theoretically, I don't think it is right to ask me to convince everyone
one by one. In practice, at this moment, I see only a few packages
calling systemd-sysusers:
tomcat9
connman
elogind
knxd
rkt
so it looks like a reasonable amount of bugs to report.
> 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.
Let me tell you a bit about my motivations...
I dislike the design of a 55k binary that can be replaced by a 2.5k tiny
shell script, as opensysusers demonstrates (and even, 200k+ if linked
statically with systemd, as Ansgar demonstrated).
I also find it fun to write shell scripts, and I'm not having a lot of
fun with C code (which I can do, but not really enjoying it).
These are probably the main motivations behind packaging opensysuser.
There's also the well known thing that systemd upstream rejects a
variety of patch classes, like the ones allowing non-linux systems, for
example. This isn't very much inviting, unfortunately. But that's not
really my thing (I'm not so much interested in kFreeBSD or Hurd...). I
do like the fact though, that maybe one day OpenRC will implement the
parsing of .service files as Xu told about, and then it can become nice
to have opensysusers and opentmpfiles.
On 1/29/20 7:29 PM, Gunnar Wolf wrote:
> I mean - We should encourage people to use /bin/sysusers. Now, if
> systemd-sysusers grows a piece of functionality that open-sysusers
> is not willing to adopt (or vice versa)
Thanks for considering the "or vice versa" possibility!!! :)
> following past examples, I
> believe a package set to predepend on systemd-sysusers should be able
> to call /bin/systemd-sysusers — And a package set to predepend on
> open-sysusers can do likewise.
This feels reasonable to me. Even better if this goes into the policy.
I've read many telling about a potential new functionality that would
not be implemented here or there. However, my guts feeling is that this
feels like a kind of stable API that isn't intended to grow very much,
and hopefully, will be of low maintenance. Let's see what the future
shows...
Cheers,
Thomas Goirand (zigo)
P.S: Just a quick digression: I really dislike the fact that I've
constantly read people saying "what if opensysusers lags behind". And
what about if I decide to contribute a super nice functionality that
systemd-sysusers authors didn't think about? Could everyone at least
attempt to consider that this is a possibility as well? That innovation
doesn't come *only* from systemd? Also, best would be if we keep both
compatible, and hopefully, this will be the case over a long period of time.
Reply to: