[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



]] Russ Allbery 

> Tollef Fog Heen <tfheen@err.no> writes:
> > ]] 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.
> 
> Thanks!  I do think that argues for a clear testing plan if someone
> proposes a change in how the dependencies are structured to avoid
> upgrading to it.

Right.  I think the right approach is to upgrade unless the user vetoes
it, but that's something reasonable people can disagree about.  (I've
come around to the idea that we should prompt on upgrades, as much as I
loathe prompts.)

> >> 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.
> 
> Right, my point here is that I don't think we should choose libpam-systemd
> dependency order purely on the basis of perception of how many bugs there
> currently are in the native systemd support versions the systemd-shim
> support.  That's partly a special case to this particular transition:
> there is obviously huge controversy over which approach is better for the
> average user, and both "sides" feel like the other program is obviously
> more buggy.

I can agree with that.  The other argument for having libpam-systemd
depend on systemd-sysv | systemd-shim rather than the other way around
is that systemd-sysv is the default (in Debian), the recommended (by the
maintainer) and the most well-tested fulfiller of the dependency.

> systemd-shim working properly is probably going to be RC for jessie.  I
> don't think there's any way to avoid that unless it's so bad that the
> people who are working on it say that there's no way that it can be stable
> for jessie and give up on that.  I don't think that's very likely.

No disagreements from me here.

> So avoiding it in dependencies because it has RC bugs doesn't, in that
> sense, help us get jessie out the door faster, because I doubt we're going
> to release jessie until it's in a reasonable state anyway.

If it makes you happier, we can avoid it as the preferred solution for
the reasons listed above.  I'm not picky. :-)

> Maybe I'm analyzing this wrong and it's more likely than I think that
> people are going to give up on getting systemd-shim working, or the
> project is going to be willing to release without it working, but I'm
> pretty dubious.

I'm less concerned about whether -shim works or not (since my main
concern is whether systemd itself works correctly or not).  I'm more
concerned about it breaking things for people who are using systemd
(directly or indirectly).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


Reply to: