On 02/12/2014 04:10 AM, Simon McVittie wrote: > Wasn't there some plan to have OpenRC look for its "runscripts" in a > parallel directory alongside init.d as well as in init.d itself, and > treat /etc/openrc-init.d/foo (or whatever) as a replacement for > /etc/init.d/foo? Then you could just say "OpenRC runscripts go in > /etc/openrc-init.d, LSB-style init scripts[1] go in /etc/init.d" and > everything Just Works.
This is currently just an idea, but it's not implemented (and nobody has yet stated intention to start implementing this). I honestly believe it wouldn't be more than a few lines of C code (it doesn't seem hard to change a loading path, right? hum... I'm sure it will be different when looking at the actual code! :)), so it doesn't have my focus right away now. > If you're keen on using OpenRC, I would strongly recommend that > approach. systemd ignores /etc/init.d/foo if it finds a corresponding > foo.service in its own directory, and that feature has made it easy to > add systemd units (.service files) per-package without needing much > special coordination. Upstart doesn't do that (/etc/init.d/foo has to be > patched to not do anything if it detects that init is Upstart and > /etc/init/foo.conf exists) which has given it much more complicated > Policy implications. > > If LSB-style init scripts disappear completely after jessie, OpenRC > runscripts could in principle move to /etc/init.d at that point, > although I don't really see much benefit in that. > > S > > [1] i.e. the ones that work equally well (or equally badly, depending > on your point of view) with sysv-rc, file-rc, insserv, Upstart, > systemd, OpenRC etc. > Probably you are right and I should review my priorities! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6480.8020...@debian.org