I think the better approch should be insert several package with
-initsystemname in debian with a conf file for the system with

init=systemd
maindb=pgsql
mainwww=apache2


I just push the example but it can be usefull for automatic install and
configure.

I don’t know if its realistic.

On 18/09/2019 16:22, alecmaillist@??? wrote:
> The following is a write-up I posted on the dev1galaxy forum a few
> days ago, but reposted here for more exposure.
>
> While I can not consider myself a veteran among the linux community
> (quite the contrary actually), I hope to help lay the groundwork for
> getting support for the various other inits that have just as much
> potential in production as sysvinit. To do this, I have decided to
> separate this broad topic into different sections. Throughout these
> sections I will use “Debian” as well as “Devuan”, as this could help
> fix Debian as well and lead to greater collaboration between the two
> distributions.
>
> Inits Overview
>
> Systemd
>
> Currently, from how I understand it, the two main inits supported on
> Debian are systemd and sysvinit. Sysvinit is treated as a second class
> citizen compared to systemd, although the support is still far better
> than inits such as openrc and runit (more on those two later).
> According to anti-systemd critics, systemd is not that hard to
> uninstall and replace with sysvinit. This claim is correct, but also
> very much not correct. The steps to remove systemd and install
> sysvinit are thankfully provided here
> <https://www.reddit.com/r/initFreedom/comments/cpj1ya/a_howtoremovesystemdfromdebianbuster_post_i_made/>.
> Even a normal user could follow these directions given enough time,
> but it comes with big caveats. Many packages are specifically built
> against systemd, and will not install without it. Even if they don’t
> strictly depend on it, they still make use of the libsystemd0 library,
> which Devuan has been unsuccessful in removing. There’s also the issue
> of systemd trying to force its way back in even after fufilling all
> the directions, leading to a big mess. In layman terms, systemd is
> easy to uninstall, but hard to keep from reinstalling. This is not
> entirely systemd’s fault, but also on developers that build their
> software this way.
>
> Sysvinit
>
> Now, let’s say you decide to uninstall systemd and replace it with
> sysvinit, as you don’t think systemd reinstalling itself will be an
> issue. As a second and easier option, you decide instead to install
> Devuan and have sysvinit installed by default, with any of the
> possible caveats listed in the directions taken away. If you prefer
> good old-fashioned bash scripts, and /etc/initab for modifying the
> runlevels, what processes to start and monitor, etc., that’s great for
> you! Supporting that as an option is necessary for backwards
> compatibility, and for many people, “it just works”. However, writing
> sysvinit scripts can be a hassle, as they are shell scripts through
> and through. It is hard or at least non-obvious to support daemons
> starting on demand. Sysvinit scripts are not really user edit-able
> configuration, as discussed here
> <https://lists.debian.org/debian-devel/2013/05/msg01787.html>. For me,
> the biggest turnoff is no real process supervision, e.g. daemons are
> not automatically restarted when they crash. As such, should sysvinit
> really be the only viable alternative to systemd on Debian? But wait,
> what about…
>
> Openrc
>
> Openrc is provided as an alternative service manager from the Devuan
> installer, which is already a step up from Debian. However, this is
> far from a replacement to sysvinit. In fact, it simply runs atop it.
> Sysvinit scripts are still used during initialization, and no openrc
> run scripts are provided as replacements for the various sysvinit
> scripts used in starting services. In recent versions of Openrc, it
> comes with its own init. This skips inittab and boots openrc directly,
> but since it still uses sysvinit scripts, it’s noticeably slower
> <https://unix.stackexchange.com/questions/472706/is-it-possible-to-run-devuan-ascii-with-openrc-init/492305>.
> Also, without providing getty scripts, the user won’t even reach the
> login prompt. Gentoo provides all the run scripts we could ever need,
> and so bringing them over is not an impossibility. Why bother using
> openrc run scripts and using openrc as an init and a service manager?
> The scripts are much easier to read, and process supervision would be
> handled much more cleanly. There’s also faster boot times and better
> overall performance, but your mileage may vary on those claims.
>
> Runit
>
> Runit, compared to openrc and sysvinit, is incredibly simplistic.
> Perhaps too simplistic for some users, but it makes creating services
> a breeze. Compared to the runlevels in sysvinit or openrc, there are 3
> stages:
>
> 1: One time initialization tasks.
>
> 2: Run runsvdir (/etc/runit/runsvdir/default, single, etc. runlevels).
>
> 3. Halt or reboot the system.
>
> Void Linux provides all the initialization tasks and services we need,
> but Debian throws all of that out the window in favor of using
> sysvinit scripts for initialization (more on this later). Even if this
> is not an issue for some users, there is still the problem of no runit
> scripts being provided.
>
> Init Compatibility
>
> The biggest problems facing init compatibility are as follows:
>
> File Conflicts
>
> First, where it all begins: /sbin/init. There are three packages that
> provide the inits: sysvinit-core, openrc, and runit-init.
> sysvinit-core installs init to /sbin/init. Openrc installs init to
> /sbin/openrc-init. Runit installs init to /sbin/init. sysvinit-core
> conflicts with runit-init, so there are no problems there. Openrc does
> not bother with at least symlinking /sbin/openrc-init to /sbin/init.
> This is where it gets tricky. if I wanted the openrc package to handle
> changing the init, it would have to conflict with sysvinit-core. Users
> who want to run openrc atop sysvinit would be out of luck if we did it
> this way. With this in mind, I propose a change to the openrc package:
> split /sbin/openrc-init into its own package, and have it install to
> /sbin/init instead. Now sysvinit-core, openrc-init, and runit-init
> will conflict with each other, and openrc can still be installed
> separately. To make them conflict, have them provide the init package.
> Next, we move on to power commands: halt, poweroff, shutdown, and
> reboot (I probably missed a few). As each init system provides their
> own power commands, these commands will conflict if they are installed
> together. Moving the commands into the init packages, if they’re not
> already there, would fix the issue. sysvinit-core already does this,
> in which case, perhaps renaming openrc-init and runit-init to
> openrc-core and runit-core would be a more consistent naming scheme.
> I’m not sure how this would affect running openrc atop sysvinit, runit
> atop openrc, and vice versa. Openrc has support for using runit for
> supervision. Next, the biggest source of conflicts: /etc/init.d.
> Specifically, the services installed there by sysvinit and openrc. For
> user choice, you could have openrc-core or runit-core installed along
> with the initscripts package, and use those scripts for
> initialization. However, what if you wanted to use openrc or runit
> initscripts instead? A lot of openrc initscripts have the same file
> names as sysvinit initscripts. Modifying openrc to include the
> initscripts, and then making openrc provide the initscripts package is
> one solution. This could be an issue for users who suddenly can no
> longer use sysvinit initscripts with openrc installed. Another
> solution is splitting openrc initscripts into its own package,
> initscripts-openrc. Runit would use initscripts-runit. Now
> initscripts, initscripts-openrc, and initscripts-runit would conflict.
> While this solves the file conflict issue among scripts during initial
> installation, it does not solve the issue of file conflicts that arise
> from packages that provide their own sysvinit scripts. This is a
> touchy problem, and deserves its own section as a result.
>
> Service Conflicts
>
> In init fairness, openrc and runit services should be provided. One
> solution is having each service be its own package. For instance,
> nginx-openrc, php-fpm-openrc, nginx-runit, and php-fpm-runit. The
> problem is that nginx and php-fpm already provide their own services
> in /etc/init.d. The same rule applies for countless other packages in
> Debian’s repositories. Why not just separate the sysvinit services
> into their own packages as well? As I discussed with other developers,
> the amount of effort that would take would be insurmountable. Also,
> when switching to another init, all service packages for that init
> would need to be replaced with equivalents for the new init.
> Automating these tasks somehow would ease development.
>
> Helpers
>
> init-system-helpers provides tools that are necessary for switching
> between the various init systems in Debian, but I’m not very
> knowledgeable with it. I think the tools in particular to pay
> attention to are invoke-rc.d and update-rc.d, as invoke-rc.d is
> executed on package service installation, and update-rc.d is executed
> on package service upgrade.
>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev