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.
signature.asc
Description: This is a digitally signed message part.