Hello Russ, Russ Allbery [2014-10-18 20:59 -0700]: > When one of you has a chance, could you update this bug with the current > thinking around how to handle upgrades I'll leave this to the Debian maintainers, as I'm mostly responsible for the Ubuntu side, haven't really discussed this with the two Michaels/Tollef/Marco, and I don't feel qualified to speak for the Debian systemd team. My personal opinion: Given how close we are to the release and how many regression reports we still get, it seems prudent to not change the currently running init systems for upgrades for Jessie yet, but only set up systemd for new installs. I know this is not really in the spirit of the TC decision to make systemd the default init system, but at this point in time it might be the pragmatic compromise. The systemd package gets literally swamped with bug reports (of all kinds of usefulness/quality), and there's simply not enough maintainers to keep up with the flood. Many of those are indeed not actual bugs in systemd, but bugs in other packages, local misconfiguration, or mere misunderstanding, but a fair amount *are* bugs in our integration (for the release it doesn't matter that much whether they are in systemd itself or other packages). The one thing that I'd really like to avoid is interactive prompting. As much heat as the init system debate produced, from an user's POV it's pretty much a tempest in a teapot. Quite frankly, as a user I don't care that much about init systems, I just want my system to boot and "apt install mysql" to DTRT. Moreso, do we really expect a user to make this decision on upgrades? Look how hard it was even for us as DDs or the TC to make an informed decision -- I really don't want to push this to the user: [ ] Install init system A (may degrade some things) [ ] Install init system B (may break some things) IMHO it's a distro's job to make this qualified decision for the user based on which system he upgrades or installs. > around the ordering of dependencies in libpam-systemd, and some of > the other ideas (such as attempting to detect systems with > /etc/inittab configuration or init scripts that don't follow > systemd's assumptions) raised in those threads? I haven't looked at those in detail. It's great to see that people work on such heuristics for upgrades, but TBH it always takes a while to stabilize those. > I would be particularly interested in your take on the analysis that Steve > Langasek posted to the debian-devel thread on why listing systemd-shim as > the first alternative dependency for libpam-systemd makes sense and should > not cause any negative effects for systemd users. As https://bugs.debian.org/765101 showed, installing systemd-shim has not always been entirely inert/regression free under systemd as pid 1, but to be fair this has been the only bug of that kind ever, and there's a better solution proposed in that bug which will make this never happen again. The other direction (running sysvinit or upstart with -shim) has not been so unproblematic though, as systemd-shim's bug list shows. This definitively needs some love, but then again we've run this for a fair while in Ubuntu (even in our 14.04 LTS) without too many problems. So my feeling is that we can certainly stabilize -shim by the jessie release. (We need to do that anyway, as we need to support sysvinit regardless of what we do on upgrades/new installs.) Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature