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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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.

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. And that a package with a Depends on a
particular systemd version should be able to depend on features from
that version; alternatives would allow an old version of opensysusers to
be used instead (unless systemd kept adding conflicts against
opensysusers whenever they add a new feature, something I doubt anyone
would be happy with).

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

(Of course, there is the problem with temporarily having no file
there... but I suspect that could be documented around as the lesser of
evils. Especially if done with --no-rename, so it'd be a very short time.)

Reply | Threaded
Open this post in threaded view
|

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

Svante Signell-2
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
 <install systemd-{sysusers,tmpfiles]>
else
 <install open{sysusers,tmpfiles}>
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.



Reply | Threaded
Open this post in threaded view
|

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

Svante Signell-2
In reply to this post by Anthony DeRobertis
On Wed, 2020-01-29 at 16:49 +0100, Didier 'OdyX' Raboud wrote:

> 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;

* E) systemd is not available on non-Linux

Reply | Threaded
Open this post in threaded view
|

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

Anthony DeRobertis
In reply to this post by 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).

Reply | Threaded
Open this post in threaded view
|

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

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.