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/ _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng