Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Russ Allbery]

Thanks, Tollef!  Okay, so there does appear to be a conflict here.  It
sounds like your primary technical concern, not addressed by Martin's
mail, is that getting the dependencies right to install systemd on initial
install but not upgrade to it are tricky and have a lot of corner cases,
and you feel like it's late in the release process to make that change.
(This is apart from the general feeling that users would be better off
with the default, which is more of a judgement call about policy.)

Is that a fair summary?

One specific point on the libpam-systemd issue:

Tollef Fog Heen <tfheen at err.no> writes:

> In a steady state, this would probably be ok. However, we've so far seen
> two instances of -shim breaking for systemd users
> (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by
> shipping outdated security policies. We are worried that this will
> happen again on future updates of systemd.

> We are also worried about it still having release critical bugs and the
> feedback we are hearing from the desktop maintainers is that they see
> bugs which are tracked down to bugs in -shim. We therefore don't believe
> that is a good choice for desktop users.

I don't particularly like this argument.  This is the reason why we should
fix bugs in systemd-shim and be sure that it's RC-free in the release, not
a reason to not install it unless those bugs can't be fixed.  In general,
we fix software that has bugs rather than avoid installing it, unless
those bugs aren't fixable.

I would even go so far as to say that it's good that we're exposing these
bugs now, during our release preparation process, so that they can be
fixed prior to jessie.  We need systemd-shim to work properly in jessie if
we can find the resources to do that work; we know that a lot of users
will want to continue using sysvinit for jessie.  systemd is a big change,
and, even if one thinks that the same thing that happpened with udev will
happen to it in the long run, as with udev we need to support both
configurations at least until one of them naturally fades away (if that
happens).  And, so far, it looks like the resources to make systemd-shim
work will be available.

> Steve's argument is that choosing sysvinit-core over systemd-sysv should
> automatically reflect on choosing systemd-shim over systemd-sysv. We do
> not necessarily think this is the case and both decisions need to be
> taken on their own.

I thought the argument was that listing systemd-shim first makes no
difference except in the case where someone does not currently have
systemd installed at all.  In other words, both of those decisions can
still be taken on their own, and that dependency order will preserve the
existing state.  Did I get that wrong?

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>