Bug#947847: please install systemd-sysusers using update-alternatives
On 2/21/20 9:10 PM, Niko Tyni wrote:
> Hi Thomas,
>
> on IRC recently you said:
>
> 23:24 < zigo> If you're just answering about update-alternatives, then you haven't paid attention to what I
> wrote in the bug report.
> 23:25 < zigo> And IMO, missing the point ...
>
> As I read the above, the systemd maintainers declined your suggestion to
> add support for handling /usr/bin/systemd-sysusers with the alternatives
> system, and you then requested the Technical Committee to overrule them.
>
> If this is not the case, could you please state clearly what you want
> us to decide.
>
> Among other things, you later mention that a separate systemd-sysusers
> package would be acceptable to you, pointing to #946456 . This avenue
> doesn't seem to be exhausted yet?
Hi,
IMO, the question is a bit more hard than just "having packages that
conflicts" or "using update-alternatives". As I think the issue is
complicated, I would have like to have the tech ctte opinion on how to
handle this case, for the Debian project at large. This is a general
opinion that I'm asking for here, and guidance on how to set the policy
for programs using systemd-sysusers, and the ones willing to
(re-)implement the systemd interface to be used as an alternative
implementation. It is my opinion that it's not good enough for the
maintainer of systemd and systemd-sysusers to just decide, as every
program using sysuser may be affected. Also please keep in mind that
this is not only about sysusers, but a more broad scope (tmpfiles is
concerned too... more may come!).
Using update-alternatives for /bin/systemd-sysusers is what I thought
was the best option, because cheap and easy to implement, with the nice
advantage that we can have both packages installed at the same time, and
programs can decide if they want a specific implementation or just any
of them.
However, if everyone is in the opinion that it's a bad idea, then I'm
open to other solutions. Having systemd package systemd-sysusers (and
systemd-tmpfiles) as separate package is also an option that would work.
It's IMO annoying, because it takes a way longer to switch from one
implementation to another, when update-alternatives instantly changes
the configuration. We also loose the co-instability, and the fact that a
given program can actively decide to use a specific implementation. But
that still works too.
However, packaging systemd-sysusers as a separate package it isn't as
easy as one may think. See #946456 for the discussion. Using
update-alternatives should have been a way easier. At the present
moment, I'm not aware of any decision from the systemd maintainer, as
this looks like not as easy as one may think.
The only thing which I do *not* want to do, is using dpkg-divert. It is
my strong opinion that this is a disservice to our users to do that,
because dpkg-divert is rarely known, yet even understood by the average
Debian users, so they wouldn't be able to even understand what happened
to their system. We should be able to find a much nicer way to implement
things.
I'm also strongly against a /bin/sysusers which both programs would
update-alternatives to, because then, we have a different implementation
than on other platforms (this would be Debian specific).
Cheers,
Thomas Goirand (zigo)
Reply to: