On 05/03/2016 12:00 PM, KatolaZ wrote:
>
> I definitely agree with you Jim, and this is certainly one aspect to
> be taken into account seriously. We should strive to allow the maximum
> flexibility in choosing an init system, ensuring that the set of
> constraints remains as small as possible.
>

I like Dan's proposal to use update-alternatives to manage which init
system to run. Usually choosing an init for a given system only happens
once during the install phase, unless you're actually testing setup of
inits.

What about an init-freedom meta-package working like mail-server and
linking to various working combinations of init + process manager +
device manager? It could provide a choice at install time, and be
changeable using dpkg-reconfigure init-freedom.

In passing, are there init script converters between various approaches?

Maintaining compatibility of a given package with various init systems
should be easy to track ("hey, your package is compatible with the
default init system [currently: sysvinit], but lacks support for:
openrc, systemd"). At least automatically create issues for this so
that package maintainers can add the relevant scripts.

That way, when we decide to switch the default init system away from
sysvinit, it's because we know most or all packages support the new
default system, *and* flipping back and forth from new to old default in
case anything goes wrong. Lotsa werk ahead.

==
hk

-- 
 _ _     We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/