Re: Bug#947847: please install systemd-sysusers using update-alternatives
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 to: