Okay, let's see how replying to a mail on my phone while in flight mode goes. Apologies in advance for formatting, quoting and vocabulary issues.
On Dec 31, 2013 4:48 AM, "Russ Allbery" <rra@debian.org> wrote:
> 2. Impact of Multiple Init Systems
> Obviously, the ideal situation for project-wide integration and support,
> and for Debian's ability to make full use of the capabilities of new init
> systems, is for all of Debian's ports to be running the same init system.
So, reading this (and trimming loss of stuff that makes sense) I wonder if it's worth stepping back and considering what happens when a package doesn't support /any/ init system. The answer I think is that the sysadmin sighs, adds their own configuration, and maybe thinks "well at least I didn't have to compile it, I guess."
That still sucks compared to the alternative of typing "apt-get install" and having it just start working, of course.
> Attempting to support multiple init systems has several obvious drawbacks:
>
> * Packages will either be limited by the functionality of the least
> capable init system or will behave differently (and have to be
> configured differently) on different ports.
I think the "Debian" way of dealing with multiple init systems would be to provide a compatibility layer for the most common packaging and admin tasks, and allowing packages to provide fancier integration where appropriate. I'm thinking of things like newaliases and sendmail, and cgi-bin and apache modules, I guess. Probably that's already covered for init systems via sysvinit compatibility and update-rc.d. Maybe there's a missing tool that could be written to let you set init specific configuration somehow, which would change /etc/default for sysv and other files for upstart/systemd.
It seems like there's maybe three separate questions then: what init system gets used by default, what work gets done to make that experience different/better than everything just having upstart or systemd pretending to be sysvinit, and what's the experience of maintaining packages to support secondary init systems and using secondary init systems on a Debian system?
(Personally, I think a gr would be better for choosing the default then having the tech ctte decide that issue, but whatever)
Based on what I've read, it seems like the ideas floating around amount to:
- if systemd is default: there would be a release goal to include systemd configs added to packages and to get daemons converted to support socket activation. Maybe other stuff too? As far as maintaining sysvinit, openrc or upstart systemd goes, you'd just have to get upstart configs written and packaged, and accept that there's an unused systemd library on your system. Multiple inits must be supported to some extent, since systemd isn't available on ports and that isn't likely to change apparently.
- upstart is default, other inits are supported: pull in Ubuntu configs for upstart for various packages. If systemd socket stuff is allowed, dummy library will probably be on most systems, if not, systemd in Debian won't be very interesting.
- upstart is default and only init supported by Debian. Same support work for Jessie, except any ports that want to stick around need to get upstart enabled.
I don't think the latter is really the Debian way - better to have the choice left in the users' hand if feasible, but it's likely a lot easier to get some impressive results that way. I think the ideal page for tradeoffs like that is in derivatives like Ubuntu personally.
> I believe Debian should take this path forward:
> 1. We should select a new init system for jessie, either systemd or
> upstart. Support for that init system should be release-critical, but
> only in the sense that the daemon works properly under that init
> system. In other words, use of the sysvinit compatibility of either
> init system is acceptable support for jessie.
So that would mean switching the init system, and decorating anything that breaks as a result RC buggy. Seems sensible.
> 2. All packages providing init scripts must continue to support sysvinit
> scripts through the jessie release. Such support will continue to be
> release-critical.
I'm not sure this makes sense, though. If someone packages a new daemon that works fine with systemd and upstart, I don't see why it shouldn't get released just because it doesn't work with two secondary init systems. Filling a wishlist bug with a patch and doing an NMU seem like they'd be sufficient here.
As far as upgrades go, if the idea is that systemd is the way to go for Jessie it seems to me that an update would by default switch you from sysvinit to systemd (likewise for upstart) - I don't think it makes much sense to do systemd/upstart for new installs but leave upgrades with sysv until Jessie+1.
> 7. After jessie, functionality between systems running the primary Linux
> init system and other init systems (including non-Linux ports) should
> be allowed to drift. In other words, there will be cases where
> features will only be available with the primary init system. Possible
> examples include security hardening, socket activation, automatic
> daemon restarts, and so forth. Packagers are under no obligation to
> port those features to other init systems, but should welcome and merge
> patches that do so. After jessie, packagers will no longer be required
> to preserve daemon configuration when the init system is switched, so
> use of such facilities as modification of upstart configuration files
> or systemd overrides may be used.
The only way maintainers are required to do these things is that either a) someone else will do it and nmu their package, or b) the release team will drop it from Jessie prior to release, no? Personally I'd be inclined to encourage patches and nmus here, and limit the rc stuff to actual belated with whatever Jessie's default end up being. I don't see any reason that wouldn't suffice to allow comparability and an aggressive approach to making use of the new default init's extra capabilities.
(I wonder if it might be interesting for the tech ctte to track the bugs for resulting from changing the init system rather than leaving it to the release team as either rc issues or release goals... Might be a good approach for some high impact improvements)
(Fwiw, I'm employed by Red Hat, but have no particular stake in systemd vs upstart, nor much knowledge about either than what I've read here)
Cheers,
aj