Hi,

> > I would suggest instead rather than orphan-sysvinit-scripts, s6
> > scripts, runit scripts,
> > who knows scripts... to create a collection of definition files per
> > service
> > with the needed variables (needs, provides, daemon, options to run
> > in foreground,
> > options to run in background, options to log, options for pidfile, 
> > run as user, run as group,
> > you name it option, option I forgot, runit_specific_options,
> > s6_specific_options) that could be
> > sourced by sysv, runit, s6 and others  to avoid duplication of
> > effort and don't
> > waste manpower.

..cut..

> You do make a valid point. One of the reasons for the fast adoption
> of
> systemd has been the easy interface (service files) for developers
> and
> packagers.
> The fastest way to make inroads with an alternative init imo is to
> adopt
> the service file format from systemd (and embrace, extend, and
> extinguish?).

I was planning to write a reply in a similar spirit to yours ;)
Moreover those service files are already there and besides the
respective interpreters there is no extra work to do per package.

The main problem in supporting systemd service files is that there are
concepts in them that other init systems can not (easily) handle and it
will become a race of adding that support versus more non-standard
stuff coming...

With best regards,
b.