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" <r...@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

Reply via email to