Hi On 2016-01-15, Alec Leamas wrote: > On 15/01/16 21:06, Michael Biebl wrote: > > Am 15.01.2016 um 21:01 schrieb Alec Leamas: > >> On 15/01/16 19:04, Russ Allbery wrote: [...] > > If the names do not match, you can ship a (static) symlink in the > > package, say you have > > /etc/init.d/foo and /lib/systemd/system/bar.service. > > Then ship a symlink like this > > /lib/systemd/system/foo.service → /lib/systemd/system/bar.service > > It's more complicated. The systemd setup is three different services, > the sysV one. There is no systemd service directly corresponding to > the sysV one. In other words, here is two things taking place at once: > a major upgrade + sysV -> systemd. No, actually it's not more complicated. There are two options to fix/ avoid this: - split the old initscript /etc/init.d/lirc into three, e.g. /etc/init.d/lircd, /etc/init.d/lircmd and /etc/init.d/irexec as I've shown in my previous mail (<[🔎] 20160115214556.25012e2e@mir>). This way both systemd and sysvinit have the same services to work with and the sysv initscripts are automatically masked on a system using systemd, favouring the corresponding systemd units instead. - XOR approach this as Michael Biebl suggested, keep the old initscript as /etc/init.d/lirc and hard-mask it for systemd so (which means systemd won't look at it and use the native systemd units instead, while non-systemd doesn't know about the masking (nor the three native systemd units) and just keeps using the old sysv initscripts as before). The result is basically the same for both options, but doing the trivial split achieves the same behaviour for all init systems - which can help potential future debugging significantly (and is a cleaner/ safer solution if other init systems would gain basic or partial support for systemd units (e.g on kfreebsd)). Regards Stefan Lippers-Hollmann
Attachment:
pgpvxzmt5ipSe.pgp
Description: Digitale Signatur von OpenPGP