:: Re: [DNG] Brief OpenRC/Jessie Discu…
Forside
Slet denne besked
Besvar denne besked
Skribent: Daniel Reurich
Dato:  
Til: dng@lists.dyne.org
Emne: Re: [DNG] Brief OpenRC/Jessie Discussion on the linux-elitists lists
On 20/05/16 09:26, Svante Signell wrote:
> On Wed, 2016-05-18 at 06:26 -0400, Boruch Baum wrote:
>> On 2016-05-18 12:11, Svante Signell wrote:
>>>> ...
>>> I'm listed as a co-maintainer of openrc (as well as ifupdown).
>>> However, due to
>>> the hostile environment in Debian I'm reluctant to do any serious
>>> work on these
>>> packages, except contributing to RC bugs being solved, to keep them
>>> in testing.
>>>> ...
>>> In my opinion the usage of init-system-helpers is wrong, why not
>>> use the package
>>> update system already available: update-alternatives? See also
>>> dpkg-divert.
>>
>> +1
>>> The idea could be developed further, to use debian's proven
>>> 'update-alternatives' method for switching amongst init-systems.
>
> What do you say, maybe we should create a package named init-freedom
> (suggested by jaromil/nexttime?) using the update-alternatives tool?
> That would override the debian init-system-helpers, which I find fairly
> obsolete, but it is probably there due to systemd-sysv.


I strongly disagree here - for several reasons:

1) changing the init system daemon is not as simple as changing which
binary gets run. There is a whole lot of other jobs that needs to be
done most of which would obviate a reboot - particularly when changing
too/from systemd. We need init-system-helpers and dh_<init-system> to
be able to ensure that packages get the mechanisms that ensure smooth
transitions between init systems.

2) Switching the init using update alternatives directly makes it easy
for packagers to hijack the init by setting a priority higher then other
init alternatives. This moves the control of default init to individual
packagers rather then as a distrobution controlled default. Also this
would allow unintended changes between inits to occur if a malicious
packager bumped the priority value of the alternatives. Having to
install a package would also ensure that the appropriated
init-system-helper hooks get run to nicely manage the transition for all
effected service daemons.

2) init-system-helpers provides a framework which uses triggers to run
hooks based on installation changes to the running init system.

Systemd uses it for some triggering some scripts related to changing
to/from sysvinit and upstart. We should further extend this
functionality to also do deployment/removal of each packages
<init-scripts | service | unit> files etc for the installed init systems
and when the init package is installed. This makes it easy to
transition between init systems but also not have a proliferation of
redundant cruft for init systems not being used or in transition.





--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722