On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yng...@gentoo.org> > wrote: > > On 26 May 2013 15:37, Michał Górny <mgo...@gentoo.org> wrote: > >> > >> Considering the design of OpenRC itself, it wouldn't be *that > >> hard*. Actually, a method similar to one used in oldnet would > >> simply work. That is, symlinking init.d files to a common > >> 'systemd-wrapper' executable which would parse the unit files. > > > > I think this idea actually makes sense. Re-using upstream work > > seems a logical idea, and could ease maintenance. Of course the > > issue is whether the OpenRC devs see any benefit in this. > > 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). > > The OpenRC devs don't have to endorse anything - sure it would make > sense to bundle it, but it could just as easily be pulled in as a dep > or used manually by a user. > > The script could ignore any unit features that aren't implemented. > You can ignore settings like auto-restart/inetd and just use the > settings that get the daemon started. > > Rich > +1 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. Robert.
