Hi Adrian, Adrian Bunk <b...@stusta.de> writes:
> On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote: >> Ian Jackson <ijack...@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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x64n56moq3....@midna.zekjur.net