On Tue, 2016-05-03 at 12:44 +0000, hellekin wrote:
> 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.

Nice idea, and name, fully supported!