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 <tfh...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org