[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removing sysV init files


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 
- 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)).

	Stefan Lippers-Hollmann

Attachment: pgpvxzmt5ipSe.pgp
Description: Digitale Signatur von OpenPGP

Reply to: