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 <email@example.com>
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 firstname.lastname@example.org
Debian Bug Tracking System
Contact email@example.com with problems
--- Begin Message ---
- To: Debian Bug Tracking System <firstname.lastname@example.org>
- Subject: please install systemd-sysusers using update-alternatives
- From: Thomas Goirand <email@example.com>
- Date: Tue, 31 Dec 2019 17:29:29 +0100
- Message-id: <firstname.lastname@example.org>
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 ---
- To: Thomas Goirand <email@example.com>, firstname.lastname@example.org
- Subject: Re: Bug#947847: please install systemd-sysusers using update-alternatives
- From: Margarita Manterola <email@example.com>
- Date: Wed, 18 Mar 2020 20:35:28 +0100
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20200221201030.GA52354@estella.local.invalid> <firstname.lastname@example.org> <email@example.com>
The technical committee was asked to overrule the systemd maintainers in
their decision not to use the alternatives system for systemd-sysusers
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
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 , 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
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
Marga on behalf of the Technical Committee.
--- End Message ---