Bug#765803: Status of prompting / notification on upgrade for init system switch?
I think you got bit by the Mail-Followup-To and your messages didn't make
it to the CTTE bug.
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.
>> 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.
Rather, I think we should decide whether we're upgrading users by default
or not upgrading users by default, on the basis of the broader situation
with both stacks plus the various social aspects to this whole argument,
and then choose dependencies that cause the fewest problems for the most
users given the background of that decision.
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.
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.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: