Re: PoC: cross-init-bridge

[Christian Seiler <christian@iwakd.de>]

[Petter Reinholdtsen]
> Have you consider the /lib/init/init-d-script approach now available
> in unstable when considering how hard it is to maintain init.d
> scripts?  It allow package maintainers to only store the package
> specific parts in their init.d scripts, and offload the complete
> implementation of the init.d script machinery to the
> /lib/init/init-d-script library/interpreter.

Oh, cool, I'll take a look. (I read some threads discussing something
like this, but I didn't know it was already in unstable.)

>> 1. Is there any interest in at least the current version of the
>> cross-init-bridge? If so, I'll add a proper build system, fix the known
>> quirks/bugs, call that "0.1" and make a debian package out of it. (I'm
>> not a DD, so somebody else will have to upload it. ;-))
> 
> I'm interested, at least. :)

:-)

>> 2. Is there any interest in the "big picture" idea? The improved
>> version of my bridge would be complimentary to the debhelper
>> proposed here, the design I'd chose is to NOT read unit files but
>> have everything as command line arguments, and that the debhelper
>> would generate the required arguments from the unit file. (That has
>> the advantage that once generated, it's easier to debug those init
>> scripts.) If that is the case, I'd volunteer to work on the improved
>> version that can start daemons when started from sysvinit.
> 
> This idea is similar to the ideas underlying the metainit package.
> Its goal was to allow package maintainers to specify the boot
> requirements once and generate automatically the files needed by
> various boot systems.  Perhaps your system could become part of
> metainit?

Yes, that seems like a plan. So in the end, that would mean:

 1. I add support for a start-stop-daemon like interface but with
    support for some of the more advanced features of systemd to
    my bridge.

 2. metainit gets support for this, i.e. using the bridge instead
    of start-stop-daemon by specifying something.

 3. There's a debhelper that can generate metainit-type init scripts
    from unit files (at least as long as the unit file is not too
    complicated), maybe even upstart jobs; and for the cases where that
    doesn't work, the package author can still use metainit directly,
    which still simplifies the whole thing quite a bit.

 4. Also note that with a few exceptions, a lot of things such as
    socket activation are not Linux-specific, they will work on the
    ports as well (it's just some inherited FDs and some environment
    variables), so with a bit of testing and some #ifdefs, the thing
    should also work on kFreeBSD and Hurd (obviously with some
    limitations sometimes).

Does that seem reasonable?

Regards,
Christian