On Tue, 3 May 2016 09:59:40 +0100
KatolaZ <katolaz@???> wrote:

> On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote:
>
> [cut]
>
> >
> > This can all be handled in each package with the package triggers
> > enabled easily with a debhelper script similar to dh-systemd which
> > makes it easy to deploy init scripts/unit files/runscripts etc in
> > their own namespace and /etc/<init-system> and only deploy them
> > when the init system is installed and removes them when it is
> > removed. This shifts the burden to package maintainers, but that
> > is the right place for them and we can make it easy to add
> > additional init-scripts by filing bugs with patches.
>
> But do we really need all that complication? Couldn't we just leave
> the initscript of each init system in a different directory and *tell
> the init system* where they are to be found? This will allow a much
> easier coexistence of different confs.

As you read my response, please keep in mind my biases. I tend to break
away from the package manager at the first hint of trouble...

If katolaz was saying "hey, it doesn't have to be that difficult", then
I agree with him. Having installed Runit, s6, and Epoch direct from
upstream developer source code, I find that the upstream developers had
the best ideas about where to put which kinds of files. To the extent
that the Devuan package conforms to what the init's developer used, you
KNOW where its files go.

I see one instance in which Devuan should depart from upstream ideas,
and that's in situations where the init's developer saw fit to create a
new directory off of the root, such as /service in daemontools.
Changing that to /var/service isn't difficult at all.

Anyway, including extra inits needn't be a big effort (except for
creating runscripts/EpochConfigs: the original developers pretty much
got everything right.

SteveT

Steve Litt
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21