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

2020-02-24 Thread Thomas Goirand
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)



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

2020-02-21 Thread Niko Tyni
(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  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   nt...@debian.org



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

2020-01-31 Thread Thomas Goirand
On 1/30/20 8:18 PM, Anthony DeRobertis wrote:
> On 1/30/20 7:02 AM, Thomas Goirand wrote:
>> This is normally solved if using pre-depends, which ensure that a
>> package is configured before using it (and not just unpacked).
> 
> Having everything using sysusers have versioned Pre-Depends on systemd |
> opensysusers would probably minimize the problem, but could potentially
> be a fair number of Pre-Depends to add. (I have no idea if non-versioned
> Pre-Depends on a virtual package works, if so that'd be better. If not,
> it'd also require adjusting them all if another alternative is introduced.)

I wrote that it could be a solution to the said problem, but I am really
not convince there's a problem at all.

Thomas



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

2020-01-30 Thread Josh Triplett
On Mon, Jan 27, 2020 at 06:16:14PM +0100, Svante Signell wrote:
> It is as simple as:
> if ps -p1|grep -q "systemd"; then

This is not the correct way to detect whether systemd is the current
init system. You want:

if test -d /run/systemd/system; then

See https://www.freedesktop.org/software/systemd/man/sd_booted.html

>  
> else
>  
> fi

"exec", not "install".

- Josh Triplett



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

2020-01-30 Thread Anthony DeRobertis

On 1/30/20 7:02 AM, Thomas Goirand wrote:

This is normally solved if using pre-depends, which ensure that a
package is configured before using it (and not just unpacked).


Having everything using sysusers have versioned Pre-Depends on systemd | 
opensysusers would probably minimize the problem, but could potentially 
be a fair number of Pre-Depends to add. (I have no idea if non-versioned 
Pre-Depends on a virtual package works, if so that'd be better. If not, 
it'd also require adjusting them all if another alternative is introduced.)


I'm not sure what the risk of dependency resolution unexpectedly 
changing a system to use opensysusers is. Or of it deciding to install 
systemd when the admin wants to use opensysusers — that is probably a 
higher risk since systemd would be listed as the first alternative.


Not saying any of this is a showstopper, of course, just that its a 
downside/potential complication to weigh.




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

2020-01-30 Thread Didier 'OdyX' Raboud
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 

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

2020-01-30 Thread Thomas Goirand
On 1/30/20 7:16 AM, Anthony DeRobertis wrote:
> There are some more that come to mind:
> 
>  * if we convert the exiting name to an alternative, there is the
>    somewhat interesting work of actually changing a file over from an
>    executable shipped in the package to an alternative, which would
>    normally be set up by postinst. That could leave an uncomfortably
>    large window during upgrade where the system would be broken (and
>    possibly not boot) if interrupted.

This is normally solved if using pre-depends, which ensure that a
package is configured before using it (and not just unpacked).

>  * if we use a new, different name, then we've introduced a
>    Debian-specific interface. One of the nice things about most of the
>    Linux world standardizing on systemd is increased cross-distro
>    compatibility; here we'd be breaking it.

That's exactly what made me think that using the original name was less
Debian wide work indeed. Though because of the binary name prefixed with
"systemd-" this is less elegant than standardizing on /bin/sysusers.

Cheers,

Thomas Goirand (zigo)



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

2020-01-30 Thread Philip Hands
Svante Signell  writes:

> On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote:
>> Simon McVittie wrote:
>> > I think we have a fairly good picture of the costs that would be
>> > incurred from using alternatives:
>>
>> Plus in the case of opentmpfiles; a pile of security issues: systemd-
>> tmpfiles addresses a number of complex races using low level
>> primitives like openat() et al. or O_PATH, while opentmpfiles is
>> implemented in shell.
>
> Do you mean that shell scripts cannot cannot handle such issues??

If you are asking that question, then I suspect that your knowledge of
the problems of shell scripting may be sufficiently limited to mean that
the only useful way to answer it would be to say:

  Yes.

> So C-code is safe by construction, do you really believe in that?

What a ludicrous question -- well done for surpassing the previous one.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature


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

2020-01-29 Thread Anthony DeRobertis

On 1/29/20 2:19 PM, Simon McVittie wrote:

I think we have a fairly good picture of the costs that would be
incurred from using alternatives: more interacting code paths to test,
potentially more configurations that are technically possible but are
not considered supported, and packages with "Depends: systemd (>= 321)"
(or indeed systemd itself, in the case of systems using it to boot)
not being able to rely on having access to all systemd 321 features,
which doesn't seem like a least-astonishment situation to be in. However,
Michael, or anyone else opposing this change: if you have anything to
add to those, please do.


There are some more that come to mind:

 * if we convert the exiting name to an alternative, there is the
   somewhat interesting work of actually changing a file over from an
   executable shipped in the package to an alternative, which would
   normally be set up by postinst. That could leave an uncomfortably
   large window during upgrade where the system would be broken (and
   possibly not boot) if interrupted. And, unlike the related
   dpkg-divert challenge, this would be on the vast majority of Debian
   systems, not only those where opensysusers is installed.
 * if we use a new, different name, then we've introduced a
   Debian-specific interface. One of the nice things about most of the
   Linux world standardizing on systemd is increased cross-distro
   compatibility; here we'd be breaking it.
 * regardless of which name (existing or new), alternatives can wind up
   pointing at nothing during the upgrade. Or if the upgrade is
   interrupted. I seem to recall that's one reason /bin/sh was never an
   alternative; seems like there is a cost in increased fragility
   (again, on all systems, not just ones with opensysusers).



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

2020-01-29 Thread Thomas Goirand
On 1/29/20 8:19 PM, Simon McVittie wrote:
> - Linux systems not booted with systemd
>   (either no init system at all, like a typical schroot or Docker
>   container, or a non-systemd init system like sysvinit)

This is very much one type of systems I have in mind, yes, and
open{sysusers,tmpfiles} could help to make them smaller. Just pulling
the whole systemd stack to add system users seems too much for very
little benefits.

> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives: more interacting code paths to test,
> potentially more configurations that are technically possible but are
> not considered supported, and packages with "Depends: systemd (>= 321)"
> (or indeed systemd itself, in the case of systems using it to boot)
> not being able to rely on having access to all systemd 321 features,
> which doesn't seem like a least-astonishment situation to be in. However,
> Michael, or anyone else opposing this change: if you have anything to
> add to those, please do.

We don't need to do "Depends: systemd (>= 321)", we could have a virtual
package provided by both implementations.

Cheers,

Thomas Goirand (zigo)



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

2020-01-29 Thread Thomas Goirand
On 1/29/20 4:49 PM, Didier 'OdyX' Raboud wrote:
> Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit :
>> This reasoning can make sense, if we agree that we should use something
>> else than /bin/systemd-sysusers and standardize on something else like
>> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
>> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of
>> severity "serious" (policy violation).
> 
> We'd first have to agree that an alternative is actually _needed_. And so 
> far, 
> the only arguments I have read in favour of providing alternatives to
> /bin/systemd-sysusers are:
> * A) it is shipped in the systemd binary package;
> * B) Having competing implementations is important;
> * C) it comes from the systemd project;
> * D) it has a systemd-* name;

Very much, B for me... I don't want to see Debian stuck in a position
where we are locked-in. This is my main motivation.

C and B are distractions that I'm not at all diving into.

A is annoying, because that imposes micro-packaging on systemd
maintainers (a 200k+ package for just this simple feature? really?), and
we try to avoid this project-wide.

Thomas



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

2020-01-29 Thread Thomas Goirand
Hi Didier!

Thanks for taking the time to reply.

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.

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... :) (just trolling here... hopefully we can have
fun in this discussion? :)).

Why is it controversial here? Maybe because upstream decided to bundle
it together with many unrelated components, as I wrote above, and prefix
the binary file name with the "systemd-" name, to give the impression
that it feels "integrated". Hopefully, you'll be able to enlighten me if
I forgot something else! :)

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. It feels like upstream also
declares systemd-sysusers as an independent component, and kind of agree
with me on this specific point.

> Let's see if I understand what you want correctly; you want Debian to allow 
> replacing systemd-specific software with alternatives, right?

It only your own opinion that systemd-sysusers is systemd specific. My
view is that what it does isn't more specific to systemd than
/usr/sbin/useradd, and that in the first place, it should have *never*
been part of a single systemd project. That's truth for many other
components of systemd, but let's not discuss this (it's out of scope).

Now that some are proposing that sysusers becomes a accepted Debian
interface, it becomes increasingly important that it becomes independent
from any other component of the system, and that it can be replaced or
reimplemented in a different way. Otherwise, maintainers scripts will
increasingly use it, and we become effectively locked-in, married
forever with systemd.

> I'm sorry, but 
> this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
> specific, and is used as such by systemd.

I am contesting this.

It's bundled with systemd, yes. It's pre-fixed with the word "systemd-"
in its binary name, yes. The idea of the static sysusers data file comes
from systemd, yes. But it stops here.

Its core functionality isn't systemd specific. We've been adding systemd
users in maintainer scripts for decades, a long time before we even knew
the word "systemd".

> If usages of it have appeared 
> outside of the systemd repository, I think it's fair to say (because of the 
> binary's name)

The binary name is precisely a distraction which you should try to
ignore, because it is very misleading.

> that they were knowingly using a systemd-specific piece of 
> software (and hence, have correctly added a "{Pre-,}Depends: systemd".

That is exactly what I would like to avoid. Hopefully, we will be able
to have:

{Pre-,}Depends: systemd-sysusers | opensysusers

or even:

{Pre-,}Depends: sysusers

if we get into the virtual package thing... And probably we should!
(maybe we can discuss this after this first discussion is done)

> If I reformulate what it seems to me you're asking, it comes accross to me as 
> "/bin/systemd-sysusers comes from systemd and it should be possible to have a 
> system without systemd installed, therefore please force the systemd 
> maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".

I don't like *at all* the way you are reformulating, and that's not
really what I'm asking for. So please allow me reject the way you are
putting things, and let me phrase it my way.

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).

To be able to allow another implementation to exist in Debian (which
happen to work anywhere, even without systemd, that's truth, but that's
not the only property of opensysusers), and a way in Debian so we can
standardize on.

This goes beyond the "I want to use sysusers in non-systemd setups". I
also want to be able to use opensysusers when I run systemd. In fact,
that's how I would like *my* own laptop / servers to run.

Anyway, there's a few ways to make this work, and both things to cohexist.

1/ Having a systemd-sysuser 

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

2020-01-29 Thread Svante Signell
On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote:
> Simon McVittie wrote:
> > I think we have a fairly good picture of the costs that would be
> > incurred from using alternatives:
> 
> Plus in the case of opentmpfiles; a pile of security issues: systemd-
> tmpfiles addresses a number of complex races using low level
> primitives like openat() et al. or O_PATH, while opentmpfiles is
> implemented in shell.

Do you mean that shell scripts cannot cannot handle such issues?? So C-
code is safe by construction, do you really believe in that?



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

2020-01-29 Thread Moritz Mühlenhoff
Simon McVittie wrote:
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives:

Plus in the case of opentmpfiles; a pile of security issues: systemd-tmpfiles
addresses a number of complex races using low level primitives like openat() et
al. or O_PATH, while opentmpfiles is implemented in shell.

Cheers,
Moritz




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

2020-01-29 Thread Matthias Klumpp
Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie :
> [...]
> I think there are three categories of systems that it might make sense
> to consider separately here. In ascending order of "amount of systemd":
>
> - non-Linux ports to which systemd does not intend to be portable (and
>   I think we can treat non-systemd-by-policy derivatives like Devuan as
>   basically equivalent to these), where the systemd implementation of
>   -sysusers simply does not exist
>
> - Linux systems not booted with systemd
>   (either no init system at all, like a typical schroot or Docker
>   container, or a non-systemd init system like sysvinit)
> [...]

For this particular case it's probably worthwhile to also consider
Zbigniew Jędrzejewski-Szmek's comment on debian-devel a while back,
where they extended systemd's interface stability and compatibility
promise based on our discussions back then.
Namely:

> Independent operation of a bunch of
> programs is now explicitly covered, and the stability promise
> has been extended to more interfaces.

>From 
>https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs
systemd-sysusers and tmpfiles are covered by this promise, as well as
a few other utilities.
So, especially for container usecases it may actually be reasonable
for the systemd maintainers to make those utilities available in a
separate package to be installed without the daemon components. That
way they would be readily available and working even on systems where
systemd isn't PID1 (of course, the daemons should also be inert until
an alternative init system starts to parse systemd service files, so
at the moment even installing the systemd package itself for these
binaries is safe).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/



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

2020-01-29 Thread Gunnar Wolf
Svante Signell dijo [Wed, Jan 29, 2020 at 08:15:36PM +0100]:
> > It's not like having two competing implementations causes much 
> > harm here.we technically _can_ allow any /bin/systemd-* to be
> > provided by another implementation, that we should (actually, I think
> > we should clearly _not_).
> 
> Of course the name should not be systemd-*. That would conflict with
> systemd upstream, and a lot of other stuff too!

Humh, where did you quote this snippet from? It includes bits from
OdyX's mail, but it's wrapped over itself. It also shows as if it were
my text (which is _not_).

> > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are
> > to allow alternative implementations of /usr/bin/system-brewmycoffee,
> 
> no way!

Please keep on reading for the full paragraph...

> > we should first push to an alternative /usr/bin/brewmycoffee, get the
> > systemd maintainers to "subscribe" to it using our great alternatives
> > system, and provide our /usr/bin/open-brewmycoffee.
> 
> Why should they be subscribing? There are other people within Debian
> who can provide alternatives.

I tend to convey that, if Debian is to support more of one
argument-compatible implementations of brewmycoffee (one of which is
systemd-brewmycoffee), I feel the systemd maintainers should be
sensible and allow its use, via the alternatives system, as
/usr/bin/brewmycoffee.

Of course, it is highly likely they will be seen as the reference
implementation and others should attempt to adopt a compatible
interface arguments-wise.

> > And I think that now, that not so many packages have yet adopted
> > systemd-derived facilities, is a great time to set this as a good
> > practice.
> 
> Is this your interpretation of the GR?

It my impression, at least.



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

2020-01-29 Thread Simon McVittie
On Mon, 27 Jan 2020 at 11:18:53 +0100, Thomas Goirand wrote:
> 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

I hope everyone involved can agree that:

- we should provide choices where their benefit exceeds their cost,
  because more choice results in a more widely applicable system;

- we should not provide choices where their cost exceeds their benefit,
  because more guarantees result in a more robust system

(By "cost" I mean developer time spent, avoidable bugs caused, etc. -
not money.)

To take some clear examples: at one end of the scale, we provide a way to
configure per-system whether /usr/bin/editor is emacs or vi or whatever,
because that's primarily about subjective, personal UI preference. At the
other end of the scale, we *don't* provide a way to configure per-system
whether /bin/tar is GNU or BSD tar: we want packages that run tar to be
able to make the simplifying assumption that on any Debian system, it's
going to be GNU tar, and we do not want to deal with bug reports from
users who have switched to an unexpected tar implementation.

So this is at least partially a question of whether making
opensysusers vs. systemd-sysusers easily sysadmin-configurable has a
cost greater or less than its benefit, or to put it another way, where
it falls on a scale between /usr/bin/editor and /bin/tar.

With that in mind: Thomas, or anyone else asking for this change, what
benefits do you expect users of Debian to obtain from being able to
install both opensysusers' implementation of the sysusers.d interface
and systemd's, and choose which one is invoked from the boot procedure
and packages' postinsts via configuration, as opposed to via package
installation/removal?

I think there are three categories of systems that it might make sense
to consider separately here. In ascending order of "amount of systemd":

- non-Linux ports to which systemd does not intend to be portable (and
  I think we can treat non-systemd-by-policy derivatives like Devuan as
  basically equivalent to these), where the systemd implementation of
  -sysusers simply does not exist

- Linux systems not booted with systemd
  (either no init system at all, like a typical schroot or Docker
  container, or a non-systemd init system like sysvinit)

- Linux systems booted using systemd

It might be helpful to consider which benefits apply to which of these
categories.

For example, the first category certainly benefits from opensysusers
*existing*, but does not directly benefit from co-installability or from
having a choice, because there is no such choice: systemd's -sysusers
is not available there, so using something non-systemd is the only option.

I think we have a fairly good picture of the costs that would be
incurred from using alternatives: more interacting code paths to test,
potentially more configurations that are technically possible but are
not considered supported, and packages with "Depends: systemd (>= 321)"
(or indeed systemd itself, in the case of systems using it to boot)
not being able to rely on having access to all systemd 321 features,
which doesn't seem like a least-astonishment situation to be in. However,
Michael, or anyone else opposing this change: if you have anything to
add to those, please do.

Thanks,
smcv



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

2020-01-29 Thread Svante Signell
On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote:

> It's not like having two competing implementations causes much 
> harm here.we technically _can_ allow any /bin/systemd-* to be
> provided by another implementation, that we should (actually, I think
> we should clearly _not_).

Of course the name should not be systemd-*. That would conflict with
systemd upstream, and a lot of other stuff too!
 
> /usr/bin/systemd-* is clearly implementation-specific. Now, if we are
> to allow alternative implementations of /usr/bin/system-brewmycoffee,

no way!

> we should first push to an alternative /usr/bin/brewmycoffee, get the
> systemd maintainers to "subscribe" to it using our great alternatives
> system, and provide our /usr/bin/open-brewmycoffee.

Why should they be subscribing? There are other people within Debian
who can provide alternatives.

> And I think that now, that not so many packages have yet adopted
> systemd-derived facilities, is a great time to set this as a good
> practice.

Is this your interpretation of the GR?



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

2020-01-29 Thread Gunnar Wolf
Thomas Goirand dijo [Wed, Jan 29, 2020 at 04:07:21PM +0100]:
> This reasoning can make sense, if we agree that we should use something
> else than /bin/systemd-sysusers and standardize on something else like
> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of
> severity "serious" (policy violation).

Yes for the general case, no for specifics.

I mean - We should encourage people to use /bin/sysusers. Now, if
systemd-sysusers grows a piece of functionality that open-sysusers
is not willing to adopt (or vice versa), following past examples, I
believe a package set to predepend on systemd-sysusers should be able
to call /bin/systemd-sysusers — And a package set to predepend on
open-sysusers can do likewise.



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

2020-01-29 Thread Gunnar Wolf
I just want to subscribe with a very big +1 to what OdyX has said here:

Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]:
> (...)
> > So I am in the opinion that "as long as it's properly hooked in the
> > packaging system and boot sequence" simply doesn't work in this case, as
> > systemd-sysusers could be called from virtually anywhere.
> 
> That's exactly the point: if it's so good that it has become used in many 
> places, changing the binary behind the scenes is clearly premature at this 
> point.
> 
> If I reformulate what it seems to me you're asking, it comes accross to me as 
> "/bin/systemd-sysusers comes from systemd and it should be possible to have a 
> system without systemd installed, therefore please force the systemd 
> maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
> 
> My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, 
> with 
> a systemd-* name 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.
> 
> That said, taking a step back and looking at the larger picture, if what you 
> wish is a Debian in which one can pick their preferred sysusers' 
> implementation, what about discussing the pertinence of a "parent"
> /bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if 
> the 
> systemd maintainers agreed to register /bin/systemd-sysusers as alternative 
> to 
> /bin/sysusers).
> 
> With this in place, you could go to maintainers who _have_ already used
> /bin/systemd-sysusers to try convince them to use the /bin/sysusers 
> "standard" 
> interface instead. We have this for 'httpd', 'default-mta', what about having 
> a virtual 'sysusers' ?
> 
> All-in-all, I think the question you're asking is misguided: it's not because 
> we technically _can_ allow any /bin/systemd-* to be provided by another 
> implementation, that we should (actually, I think we should clearly _not_). 
> But not having a /bin/systemd-sysusers' implementation that can be toggled in-
> place through alternatives doesn't hinder you from proving that the competing 
> implementation is better (faster, less systemd, etc); there are various ways 
> to do this; dpkg-divert, another non-"systemd-*" parent alternative, or 
> others. If /usr/bin/opensysusers-sysusers is really that good, have you tried 
> talking to maintainers using /bin/systemd-sysusers to see if they would like 
> to swap to it? It's not like having two competing implementations causes much 
> harm here.

/usr/bin/systemd-* is clearly implementation-specific. Now, if we are
to allow alternative implementations of /usr/bin/systemd-brewmycoffee,
we should first push to an alternative /usr/bin/brewmycoffee, get the
systemd maintainers to "subscribe" to it using our great alternatives
system, and provide our /usr/bin/open-brewmycoffee.

And I think that now, that not so many packages have yet adopted
systemd-derived facilities, is a great time to set this as a good
practice.


signature.asc
Description: PGP signature


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

2020-01-29 Thread Didier 'OdyX' Raboud
Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit :
> This reasoning can make sense, if we agree that we should use something
> else than /bin/systemd-sysusers and standardize on something else like
> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of
> severity "serious" (policy violation).

We'd first have to agree that an alternative is actually _needed_. And so far, 
the only arguments I have read in favour of providing alternatives to
/bin/systemd-sysusers are:
* A) it is shipped in the systemd binary package;
* B) Having competing implementations is important;
* C) it comes from the systemd project;
* D) it has a systemd-* name;

Out of these, A is the most convincing, B is mildly so; C & D are absolutely 
irrelevant IMHO. If you're concerned by A, the request becomes:
> Please ship systemd-sysusers in a separate package for finer granularity and
> smaller installation size for non-systemd systems

If you're concerned by B, I don't think you need anything from systemd; just 
convince enough maintainers that a non-systemd implementation is important, 
and get them to change their scripts and dependencies to opensysusers. If you 
really want a single sysusers implementation per system (what's the argument 
there?), then go the /usr/bin/sysusers alternatives' route, and convince 
maintainers to move to that virtual package.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.


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

2020-01-29 Thread Didier 'OdyX' Raboud
Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.

Only words, I know, but let's try to answer technical points, not address 
people. "Talk to the space, not to individuals"
 
> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.

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".

I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should 
be allowed to provide an alternative to /usr/sbin/cupsd.

Let's see if I understand what you want correctly; you want Debian to allow 
replacing systemd-specific software with alternatives, right? I'm sorry, but 
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared 
outside of the systemd repository, I think it's fair to say (because of the 
binary's name) that they were knowingly using a systemd-specific piece of 
software (and hence, have correctly added a "{Pre-,}Depends: systemd".

Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without 
systemd, or on a host booted with a different init system; I'm only saying 
that usages of systemd-sysusers must have appeared with full knowledge of 
using the systemd-sysusers binary from the systemd project.

> So I am in the opinion that "as long as it's properly hooked in the
> packaging system and boot sequence" simply doesn't work in this case, as
> systemd-sysusers could be called from virtually anywhere.

That's exactly the point: if it's so good that it has become used in many 
places, changing the binary behind the scenes is clearly premature at this 
point.

If I reformulate what it seems to me you're asking, it comes accross to me as 
"/bin/systemd-sysusers comes from systemd and it should be possible to have a 
system without systemd installed, therefore please force the systemd 
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".

My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with 
a systemd-* name 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.

That said, taking a step back and looking at the larger picture, if what you 
wish is a Debian in which one can pick their preferred sysusers' 
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the 
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to 
/bin/sysusers).

With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard" 
interface instead. We have this for 'httpd', 'default-mta', what about having 
a virtual 'sysusers' ?

All-in-all, I think the question you're asking is misguided: it's not because 
we technically _can_ allow any /bin/systemd-* to be provided by another 
implementation, that we should (actually, I think we should clearly _not_). 
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing 
implementation is better (faster, less systemd, etc); there are various ways 
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or 
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried 
talking to maintainers using /bin/systemd-sysusers to see if they would like 
to swap to it? It's not like having two competing implementations causes much 
harm here.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.


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

2020-01-29 Thread Raphael Hertzog
On Tue, 28 Jan 2020, Thomas Goirand wrote:
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

It's not that ugly if you consider that you are in an experimental phase
where you want to test opensysusers.

Also you seem to imply that the common interface is the systemd-sysusers
binary. I don't think that this is necessarily the case. The common
interface is the file format. The name of the program creating the users
is not important as long as it's properly hooked in the packaging system
and boot sequence.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



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

2020-01-28 Thread Philipp Kern
On 1/28/2020 1:33 PM, Thomas Goirand wrote:
>> It'd need to be a script that the systemd maintainers feel reasonably
>> confident will always run systemd's implementation when systemd is
>> running, to avoid the mixed implementations issue.
> 
> Not at all. Systemd maintainers have no say if someone wishes to
> implement things in another way, the same way there's gawk and mawk,
> implementing the same thing. If we don't allow such things, then really,
> Debian is doomed.

The interface in question here is "awk". So if the interface would be a
hypothetical "update-sysusers", then this could be shared with
alternatives. I completely understand the view of the systemd
maintainers that "systemd-sysusers" as a binary should be provided by
their package rather than an alternative.

>> Strikes me as there is a possible solution, though: have opensysusers
>> dpkg-divert it and put a shell script in its place that checks which
>> init system is running, and exec's the right sysusers based on that.
> 
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

If the problem here is that everything embeds a call to systemd-sysusers
directly and you want to provide a different intermediate interface
eventually then diverting it as a workaround in the meantime seems sound
to me, no?

So far I see you present a single option rather than trying to negotiate
within the option space. Good escalations are not "Moreover, I don't see
why /usr/bin/systemd-sysusers would be any different from let's say
/usr/bin/awk." but trying to present the two opposing viewpoints and
potential solutions to them.

Kind regards
Philipp Kern



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

2020-01-28 Thread Thomas Goirand


Anthony DeRobertis 
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.

You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.

> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.

Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.

> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.

This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.

> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.

Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).

> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.

Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.

I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.

Cheers,

Thomas Goirand (zigo)

P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.



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

2020-01-27 Thread Michael Biebl
Am 27.01.20 um 14:19 schrieb Michael Biebl:
> Am 27.01.20 um 11:18 schrieb Thomas Goirand:
> 
>> It is my view that what you're proposing would be a lot more work for on
>> valid reason. 
> 
> opensysusers as implementation will always lag behind systemd-sysusers
> and/or be incomplete, it might even be incompatible.
> This has the potential to negatively effect a systemd installation
> leading to a less robust system. Those issues will likely be hard to
> diagnose where we as maintainers have to spend time which would be
> better spent elsewhere.
> And all that for what? I don't see a compelling use case why swapping
> out the native reference implementation and running a combination which
> is untested (and unsupported by systemd upstream) would be a good idea.

I'm not subscribed to this bug report, so if the CTTE want's further
feedback on this issue from my side, please CC me.

Michael



signature.asc
Description: OpenPGP digital signature


Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]

2020-01-27 Thread Svante Signell


--- Begin Message ---
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
> 
> Strikes me as there is a possible solution, though: have opensysusers 
> dpkg-divert it and put a shell script in its place that checks which 
> init system is running, and exec's the right sysusers based on that.

It is as simple as:
if ps -p1|grep -q "systemd"; then
 
else
 
fi

> This wouldn't affect systemd-only machines (as opensysusers would not be 
> installed at all), and would do the right thing if someone has installed 
> two init systems to, e.g., consider switching. It'd need to be a script 
> that the systemd maintainers feel reasonably confident will always run 
> systemd's implementation when systemd is running, to avoid the mixed 
> implementations issue.



--- End Message ---


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

2020-01-27 Thread Svante Signell
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
> 
> Strikes me as there is a possible solution, though: have opensysusers 
> dpkg-divert it and put a shell script in its place that checks which 
> init system is running, and exec's the right sysusers based on that.

It is as simple as:
if ps -p1|grep -q "systemd"; then
 
else
 
fi

> This wouldn't affect systemd-only machines (as opensysusers would not be 
> installed at all), and would do the right thing if someone has installed 
> two init systems to, e.g., consider switching. It'd need to be a script 
> that the systemd maintainers feel reasonably confident will always run 
> systemd's implementation when systemd is running, to avoid the mixed 
> implementations issue.





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

2020-01-27 Thread Michael Biebl
Am 27.01.20 um 11:18 schrieb Thomas Goirand:

> It is my view that what you're proposing would be a lot more work for on
> valid reason. 

opensysusers as implementation will always lag behind systemd-sysusers
and/or be incomplete, it might even be incompatible.
This has the potential to negatively effect a systemd installation
leading to a less robust system. Those issues will likely be hard to
diagnose where we as maintainers have to spend time which would be
better spent elsewhere.
And all that for what? I don't see a compelling use case why swapping
out the native reference implementation and running a combination which
is untested (and unsupported by systemd upstream) would be a good idea.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature


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

2020-01-27 Thread Thomas Goirand
On 1/25/20 5:05 PM, Michael Biebl wrote:
> Control: tags -1 + wontfix
> 
> Hi Thomas
> 
> On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand  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)