]] Russ Allbery > Tollef Fog Heen <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
