On Thu, 18 Jun 2015 16:58:59 +0200
Mat <mat@???> wrote:


> So in general I think that this approach - moving init system specific
> things out of the main package and providing one package per init
> system
> - is a good way of supporting multiple init systems.
>

> For instance:
> openssh-server         - the ssh daemon, stripped of its startup
> script openssh-server-sysv    - the traditional sysvinit startup
> scripts openssh-server-run     - startup scripts for runit
> openssh-server-epoch   - startup scripts for epoch
> openssh-server-openrc  - startup scripts for OpenRC
> openssh-server-systemd - why not?
> etc..

Hello diversity!

It's quite for a while that I'm reading this formidable list, now it's
time to spend my actual two cents: Since I've read the following mail
from the "epoch feature request" thread...

On Wed, 17 Jun 2015 11:25:28 -0400
Steve Litt <slitt@???> wrote:

> Here is the sum and total of information that could ever be needed for
> an Epoch Object (service, thing, whatever):
>
(...)
>
> Most of the preceding can safely be left to its default and remain
> unmentioned. Some of it is defined by the LSB header. My point is, by
> the time all is said and done, an Epoch object is pretty darn simple,
> pretty much like a systemd unit file (which is probably what we
> *should* kidnap as our source of conversion data).


...I wonder, if it is necessary to create that many (daemon*initsys)
packages, as Mat (and others?) proposed - or if it was possible to
create some standardized per-daemon config file, to be parsed by
init-system-specific scripts into suitable configurations / init-
scripts.

On the long run, these "universal" definitions could be maintained with
their respective daemon, while the particular parser-scripts might
become part of the init-systems, possibly as an extra package.

This should provide a simple way of solving package dependencies, while
bringing greatest flexibility, if these init-system-specific scripts
were invokable in some interactive mode, asking the user (or a higher-
level configuration tool) which daemons to take care of.

Disclaimer: I'm more of an advanced user than a developer, but willing
to get my hands dirty if this idea should prove to make sense for at
least a subset of the existing (and upcoming:) init-systems, perhaps
even including systemd.

Regards,

Florian


--
"A specialist is a barbarian whose ignorance is not well-rounded."
Stanislaw Lem, His master's voice