Le jeudi, 30 janvier 2020, 00.28:36 h CET Thomas Goirand a écrit :
> 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.
The way I look at this is: the "systemd software team" added a software they
had a need (or a vision) for, and added it in their usual way: by adding it in
their repository [0]. Then other projects noticed this new piece of software
and found it interesting, hence started to use it, because it filled a need
they had, or replaced older codepaths with this new tool.
> 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... :)
I'm not sure whether you brought this example on purpose, because Debian
already ships adduser (in perl), and useradd (in C). And the perl version is
the enhancement of the C version. But they don't carry the same name. And this
matters; it's a question of honouring interface promises.
To answer your question directly: I don't think Debian should ever allow to
pick between different /usr/sbin/adduser implementations, per system, no. But
it could eventually be replaced, like we migrated to dash as /bin/sh: for
Lenny it was possible to switch to dash as /bin/sh, for Squeeze it was
enforced on all hosts.
> Why is it controversial here?
Because you're asking to replace a piece of software made by the systemd
project, in the systemd repositories, shipped in the systemd package,
knowingly used by other projects as being from systemd. What would be your
stance as OpenRC maintainer if I asked you to add a update-alternatives for
/sbin/openrc-run for my /sbin/pyopenrc-run?
> 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.
Please don't use the Debian archive (and project) to prove other projects
wrong, really.
> It feels like upstream also declares systemd-sysusers as an independent
> component, and kind of agree with me on this specific point.
What I read from the systemd project on [1] is "some of our software doesn't
need to run on hosts with systemd as init". But what I understand from your
position is "as some of the systemd software doesn't need to run on hosts with
systemd as init, we can replace them with alternative software". If that's
what you're saying, I don't think the conclusion follows from the observation.
But holding the systemd software (and hence their Debian maintainers) up to
their promises (as is done in #946456) is a very good way to go, and a burden
I feel is reasonable on the systemd maintainers' shoulders. Once, and if that
is sorted out, packages would need to amend their dependencies to depend on
systemd-sysusers; opensysusers could then Conflict/Provides systemd-sysusers
for example; all this without the need for update-alternatives.
(I'd also argue that providing systemd-sysusers in its own binary package [or
systemd-utils] mostly makes opensysusers purposeless.)
> 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).
It's already possible; maintainers can use opensysusers _now_.
> > 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.
It seems you're reading systemd-* to say "comes with systemd the init system",
where I read "systemd-*" to say "comes from the systemd project". As I said
earlier, we should be _glad_ that the systemd project innovates in their space
using their namespace. Just imagine for a second if they had used
/usr/sbin/adduser (because that's what it does, right?).
> > Please let's not use this as a point of argumentation.
You can't just dismiss my points because you don't agree with them. I stand to
thinking this point is central: if the systemd package had started shipping
/usr/sbin/sysusers, you would have a _much stronger_ case for
dpkg-alternatives, frankly.
> > 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.
Indeed, I'm of the opinion that nobody _in Debian_ should be allowed to step
on systemd-*'s namespace (or on openrc-*'s namespace, or on /usr/sbin/cups*).
That does not mean that alternatives are not possible; it "just" means that
alternatives have to exist in different paths.
OdyX
[0] A debate could be held elsewhere to discuss whether it's a good practice;
I'm merely saying it's not unusual nor forbidden.
[1] https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs
> Some programs in the systemd suite are intended to operate independently of
> the running init process (or even without an init process, for example when
> creating system installation chroots). They can be safely called on systems
> with a different init process or for example in package installation
> scriptlets.Attachment:
signature.asc
Description: This is a digitally signed message part.