Re: 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?
Yes.
> One specific point on the libpam-systemd issue:
>
> Tollef Fog Heen <tfheen@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.
Based on that argument, we should install as much software as possible
on users' desktops, to ensure we expose as many weird interaction bugs
as possible. I don't actually believe this is what you mean, so if you
want to EXPN a bit, please do.
> 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.
I don't think the necessary manpower to fix those bugs is available. If
so, why are we now then at ten days before the freeze with bugs that
were made release critical in -shim more than a month ago with no
subsequent response from the maintainer?
> > 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?
Not sure, maybe Michael can comment on this bit?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: