Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Rich Freeman <rich0@gentoo.org>]

On Sun, May 26, 2013 at 6:31 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 12:12:49 +0200
> Robert David <robert.david.public@gmail.com> wrote:
>
>> On Sun, 26 May 2013 05:49:48 -0400
>> Rich Freeman <rich0@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