Bug#727708: Bits from linux.conf.au
Hi Adrian,
Adrian Bunk <bunk@stusta.de> writes:
> On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>>
>> > I'm coming round to the view that we should be planning to support
>> > multiple systems indefinitely.
>>
>> This has been my opinion all along. Various assertions that it's
>> somehow just too hard really haven't swayed me. The tricky bit, I
>> think, is to define just what "support" means in the context of
>> non-default init systems.
>
> There are at least three tricky areas:
>
> 1. init systems will have to cope with packages supplying init scripts
> in several formats they support.
Agreed. Effectively, this puts a lot of burden on individual maintainers
(and also on some external packagers) to test their packages with 2+
init systems and become familiar with how to properly mask units/handle
diverting names, what features each system supports, what the best
practices for each are, etc.
Of course, to some degree, this also needs to happen when we
transition. But having a one-time transition and doing something forever
are two very different things, and I’d be really sad if we were to
impose this kind of work on our contributors.
> 3. Switching init systems after installation.
> Assume I am currently using systemd.
> What is supposed to happen when I do "apt-get install sysvinit-core"?
One could implement a GRUB boot menu (or multiple boot entries) or some
sort of switcher, but the more important point about this is the
synchronization of init system state, i.e. which units/scripts are
enabled/disabled. The idea here is that if you disable lighttpd on
sysvinit, it should not start when you reboot into systemd and vice
versa.
Having written deb-systemd-helper (shipped in the init-system-helpers
package), I know very well how many corner cases and rough edges¹ are out
there in that respect. deb-systemd-helper was written with the intention
of getting rid of it after Debian switched to systemd. Supporting/using
it indefinitely is certainly not a good idea, and I think this is not
implementation-specific, but a general issue.
In conclusion, I’d hate a situation where we’d support multiple init
systems. I strongly recommend deciding for one init system.
① The mapping of service file names (and socket file names!) to init
script names is just one of them, but a fairly obvious and easy to
understand one. Note that there are Alias= directives in service
files, too.
--
Best regards,
Michael
Reply to: