On Sun, May 26, 2013 at 6:31 AM, Michał Górny <mgo...@gentoo.org> wrote: > On Sun, 26 May 2013 12:12:49 +0200 > Robert David <robert.david.pub...@gmail.com> wrote: > >> On Sun, 26 May 2013 05:49:48 -0400 >> Rich Freeman <ri...@gentoo.org> wrote: >> >> > Init.d scripts are just shell scripts. All somebody needs to do is >> > write a shell script that parses a unit file and does what it says, >> > and exports an openrc-oriented init.d environment. That can be >> > packaged separately, or whatever, and maybe an eclass could make it >> > easy to install (point it at the upstream/filesdir unit and tell it >> > what to call the init.d script, and you get the appropriate >> > symlink/script). >> > >> >> I would rather add shell script to parse unit and generate appropriate >> init script while building than have initscript wrapper that will call >> and parse on execution. As you said, some eclass. > > This effectively duplicates data for no real benefit. > > 2) if user modifies init.d script, systemd unit is out-of-sync. > And the init.d is rewritten (potentially with CONFIG_PROTECT) on next > upgrade. > > 3) if user modifies systemd unit, init.d script is out-of-sync. >
To clarify, I was agreeing with the use of a wrapper script - likely symlinked. It would not be compiled/generated at install time, beyond creating the symlink and maybe a conf.d file that pointed to the unit. The eclass would just streamline the installation. As you point out that keeps the configs always in-sync. It also means that if the wrapper script is upgraded to add new features all packages benefit, without needing a re-install. Rich
