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

Bug#947847: marked as done (please install systemd-sysusers using update-alternatives)

Your message dated Wed, 18 Mar 2020 20:35:28 +0100
with message-id <f95dc1f552a67f7aba8a9d7f4b8d94f6@debian.org>
and subject line Re: Bug#947847: please install systemd-sysusers using update-alternatives
has caused the Debian Bug report #947847,
regarding please install systemd-sysusers using update-alternatives
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

947847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947847
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 244-3
Severity: important


As I'm packaging opensysusers (see ITP: #947846), I would like my
package to also provide /bin/systemd-sysusers. Please install this
binary on another location, so that both systemd and opensysusers can
implement it. I am very much fine to have systemd have the priority over
opensysusers if you believe it should (I'm open to discussion about


Thomas Goirand (zigo)

--- End Message ---
--- Begin Message ---

The technical committee was asked to overrule the systemd maintainers in their decision not to use the alternatives system for systemd-sysusers and systemd-tmpfiles.

Our mailing list and IRC discussions have shown that we agree with the systemd maintainers that using the alternatives system for these files is not a good idea. Therefore, we decline to overrule the systemd maintainers.

Some additional comments on this matter:

The alternatives system has served us well when there's a clear API that implementations have to follow and there's an implementation independent location that becomes the alternative. In a case like sysusers or tmpfiles it would be perhaps make sense to use the alternatives system for a path like /bin/sysusers and /bin/tmpfiles, but it doesn't make sense to use it for /bin/systemd-sysusers.

The flip side of this is that implementing such a path would become Debian specific and the general agreement is that diverging from the rest of the Linux community for no good reason is not a good course of action. Perhaps this could be an option if the FHS was still evolving to include new tools like these, but that's unfortunately not the case.

Leaving the alternative system aside, the other two options that would allow opensysusers and opentmpfiles to be drop-in replacements for the systemd versions are: A) packages that conflict with each other and B) using dpkg-divert to divert the versions.

Shipping systemd-sysusers and systemd-tmpfiles as separate packages has been requested in [1], and there has been some work done in that direction in the bug. It seems that with the recent work done in that bug, this could possibly work. In order for this to happen, interested parties should probably go ahead and test / review the proposed solution and collaborate with systemd maintainers to find out if this is possible.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946456

On the dpkg-divert option, the rough consensus of the committee is that while this is not the most elegant solution out there, it's a perfectly valid solution for a tool that's experimental and under development. It makes sense for such a tool to divert the files that it's replacing. This is low-effort for everyone involved and lets users experiment and give feedback on the tools.

If the tool sees very significant adoption, it might make sense to eventually reconsider the strategies for dealing with multiple implementations.

Marga on behalf of the Technical Committee.

--- End Message ---

Reply to: