On 02/19/2014 10:47 PM, Michael Biebl wrote: > Am 19.02.2014 00:52, schrieb Russ Allbery: >> Henrique de Moraes Holschuh <h...@debian.org> writes: >> >>> They *HAVE* to be provided by the active init system. They are an >>> impedance matching layer (aka stable API) used by maintainer scripts to >>> interface with the active init system. >> >> If you look at the existing implementation, you'll find that the version >> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself. >> So this isn't precisely true. If we stick with the current model, then >> some (probably essential) package just needs to provide those >> implementations and accept patches to work with new init systems, but each >> init system doesn't need to provide its own version. >> >> There are some advantages to providing only one version with knowledge of >> all of the init systems given that we're supporting init system switching, >> and therefore may need to set up state for init systems that aren't >> currently running so that switching can work properly. A good example is >> registering an init script with insserv so that the correct S and K links >> are created even if the system is currently booted with a different init >> system. > > If you look at e.g. update-rc.d enable|disable, it currently has support > for systemd, upstart and sysv-rc. So whenever you enable a service, this > state is kept in sync across the different init systems (assuming the > service in question ships native support for other init systems). > > I don't find equivalent functionality in openrc's implementation of > update-rc.d
How come? I just took what was in the sysinit package! Or probably, what you are talking about is new features, which I should merge it back into the OpenRC version? 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/5304e46b.8050...@debian.org