Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
> On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> > I agree completely that it doesn't make sense for the transition from
> > sysvinit to systemd to take place via libpam-systemd rather than via
> > some core package like "init",
>
> And yet you are arguing that the libpam-systemd dependency should not be
> inverted, for political (not technical) reasons.
He did give *technical* reasons to not invert the dependency. I also
agree that it's suboptimal if the init system changes as a "side effect"
of upgrading/installing some other, seemingly unrelated, package.
However, that does not make it a good idea to install shim as a side
effect instead. At least the case where you do partial upgrades of
packages that now add a libpam-systemd dependency is one where
systemd-sysv first seems technically correct (more below).
When doing partial upgrades, I think the ideal user experience would be
to inform the user that he should do the migration to systemd at this
point before proceeding to update certain individual packages to newer
versions.
> If we decide that init *should* be automatically changed on upgrade, then
> the ordering of the dependencies on libpam-systemd is immaterial except in
> the specific case that someone has upgraded to (or newly installed) jessie,
> selected an init system other than the default, and subsequently installed a
> desktop environment on a system that didn't initially have one. In this
> case, installing the DE *definitely* should not override the user's
> explicit selection of init system.
It is also relevant if someone does a partial upgrade to current
unstable from an older system that still uses sysvinit for legacy
reasons only (and is expected to switch to systemd at *some* point in
any case). Installing shim would make the user waste effort dealing with
shim's problems, while still requiring them to deal with any
incompatibilities from the systemd transition at a later point.
Deferring some issues in this way while increasing the amount of overall
work and problems could be a valid choice in particular cases, but I do
not thing it should be the default behavior.
> If the bugs in systemd-shim are too severe to allow it to be used with
> logind (a claim that I do not agree with - and I think you and Michael are
> moving the goalposts by using the existence of bugs in
> cgmanager+systemd-shim /in general/ as a justification for delaying the
> change in dependency order), then those bugs should be marked as
> release-critical, and the determination should be made by the usual means
> whether systemd-shim should be included in the release. But it is not for
There is a difference between a package that's functional enough to be
useful for people who know what they're doing, and a package that's
suitable to be automatically installed just because people do partial
upgrades in a particular order. And it seems that systemd-shim falls in
the first camp (though I have not followed it closely myself). It may
not be RC-buggy, but "not RC-buggy" is not a sufficient quality
criterion to install it automatically if a user just wants newer GNOME
packages for example.
Reply to: