On 2/7/2012 3:41 AM, Sven Burmeister wrote:
Am Dienstag, 7. Februar 2012, 00:53:54 schrieb Cristian Rodríguez:
On 06/02/12 09:47, Sven Burmeister wrote:
I'm sure there is a packaging way to check whether systemd or syvinit is installed and install the legacy scripts accordingly when installing a service – assuming that service maintainers bother to maintain scripts for the non- default sysvinit.
Not without splitting init scripts into separate packages combined with other tricks like packageand() etc...
Of course it would take some effort. I guess that is one reason why it seems more sensible to focus on one init system for the official distribution rather than two. But it's doable for those that want sysvinit nevertheless and hence "(2) forbid them to include a LSB compliant init script" not true.
Sven
Just run a system command that attempts to get a value from systemd a la "systemd --version"
If you get anything, then you have systemd, otherwise you have init. (No worse assuming that than simply assuming init is the only thing that ever exists, which is what every spec does up to now anyways.)
Add that test to distribution rpm macros for convenience and efficiency so only one copy needs to exist instead of requiring each spec to include it, but initially a spec can include it directly just about as easily.
Then spec files can reasonably include both init and systemd support.
Some, maybe most packages could also just unilaterally include both an init script and a unit file, as long as systemd was smart enough to suspend it's "legacy" support and ignore an init script if both an init script and a unit file exist that are somehow known to apply to the same service (either the name of the init script or a value in it's comment headers exactly matches a similar name or value in the unit file.)
That would cover the case of the admin switching init systems after packages have already been installed.