On 18/06/15 13:47, Didier Kryn wrote:
>
> [...]
>
>> I wonder if now is the time to start separating out the init specific
>> configuration files, initscripts or service files, libraries and
>> binaries out into separate packages so that any particular init can be
>> supported without treading on the toes of others. The only issue I
>> can see with this is the dependency chain can get a bit hairy.
>>
>> I expect the dependency chain should be something like:
>> <daemon> depends on: init, <daemon>-sysv-init | <daemon>-epoch-init |
>> <daemon>-systemd-init | <daemon>-openrc-init | <daemon>-upstart-init
>>
>> And if each of those <daemon>-*-init packages depended on their
>> respective init system, and each of those init systems provide the
>> virtual package "init" (as is the case in Debian and Devuan Jessie),
>> then apt should be able to work out that when installing <daemon> that
>> because sysvinit-core is the package providing init that it must also
>> install <daemon>-sysv-init in order to satisfy the dependency. The
>> problem is whether changing init systems would result in pulling in
>> the new <daemon>-*-init dependency required for the new init system.
>>
>> Thoughts??
>>
>

>     This is the normal way of implementing this kind of multiple
> alternative dependencies in Debian, AFAIU. The only reason I did not
> advocate this before is that it would bring in a bunch of new packages
> each containing only one small file. But this might not be a big deal
> after all, considering it solves the problem completely, allows to get
> rid of the irritating systemd service files, and treats all other init
> systems equally.

>

>     I support this idea.
>                                     Didier

I've been using something similar with runit for years: one debian
package for each service that contains only the run scripts, some
dependency statements, and compatibility scripts for a clean integration
with debian (essentially dropping replacement for traditional sysvinit
scripts in /etc/init.d/).

I generally use sysvinit+runit on servers, but recently I started
еxperimenting with runit as init replacement and it's been a smooth ride
so far. I've got packages for that as well but they've not really been
tested much (not on production servers).

My packages were meant only for my personal use but I'm slowly cleaning
up the whole thing and putting it online so it could be useful to other
people (pushed by the systemd cabale):
git sources: http://parad0x.org/git/debian-run/
apt repository: http://parad0x.org/apt/

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..

It isn't so much work really if it's done in a systematic way. Most of
the work went in the postinst/prerm scripts to stop/start the service,
and remove/restore the traditional sysv init file: things that wouldn't
be necessary if the service package was stripped of the sysv scripts.

I know that supporting multiple init systems isn't on the priority list
for devuan, but in the longer term I think it would be a nice feature.

--
Mat <mat@???>


--
Mat <mat@???>