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

Bug#947847: please install systemd-sysusers using update-alternatives



(Sorry for the extensive quoting, see the end.)

On Mon, Jan 27, 2020 at 11:18:53AM +0100, Thomas Goirand wrote:
> On 1/25/20 5:05 PM, Michael Biebl wrote:
> > Control: tags -1 + wontfix
> > 
> > On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand <zigo@debian.org> wrote:
> >> Package: systemd
> >> Version: 244-3
> >> Severity: important
> >>
> >> Hi,
> >>
> >> 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
> >> priorities).
> > 
> > Thanks for your interest in systemd-sysusers.
> > After thinking more about this, I don't consider renaming
> > systemd-sysusers and installing it via alternatives as a good idea.
> > 
> > When systemd is installed and used, we definitely want to use its own
> > implementation.
> > 
> > My recommendation would be to install the opensysusers implementation
> > under a different binary name.
> > 
> > Alternative init systems can then decide to support sysusers by calling
> > that opensysusers binary during boot.
> > debhelper, should it get sysusers support, should generate code which
> > calls the correct binary depending on the  current circumstances.
> > 
> > Regards,
> > Michael
> > 
> > 
> > 
> 
> Hi Michael,
> 
> It is my view that what you're proposing would be a lot more work for on
> valid reason. I'm therefore re-assigning the bug to the tech-ctte,
> asking them to decided instead.
> 
> It is my view that using update-alternatives is *very* easy to
> implement, so that we can share the /usr/bin/systemd-sysuser location.
> 
> Besides the fact that, with the way you're suggesting, we'd need to fix
> debhelper (which I don't think is reasonable, as it wont be the only
> place to handle multiple cases, I'm foreseeing...), there's also the
> concern that you don't seem to agree that it'd be ok for one to use
> opensysuser instead of the systemd implementation if systemd is running.
> I do not agree with this, and I believe it is up to the users to decide
> what to do, even if we, as an operating system, must provide sensible
> defaults (which also can be discussed, but that's not the point of this
> bug report).
> 
> Moreover, I don't see why /usr/bin/systemd-sysusers would be any
> different from let's say /usr/bin/awk. The update-alternatives system is
> there exactly to handle the case we're facing today.
> 
> So, tech-ctte, please decide.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

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?
-- 
Niko Tyni   ntyni@debian.org


Reply to: