On 16/06/2015 19:47, Anto wrote:
> On 16/06/15 20:42, Roger Leigh wrote:
>> On 16/06/2015 18:14, Anto wrote:
>>> I was not really sure if script similar to update-rc.d would be relevant
>>> to epoch as the way the runlevel is being managed in epoch is different
>>> from sysvinit. That is why I am looking for other options.
>>
>> update-rc.d is an *interface* to update service registration by the
>> packaging system (or the admin). It doesn't matter if you don't use
>> rc.d/init.d directories; it's just a name resulting from historical
>> practice. You *do* need to use this mechanism to integrate into the
>> system. Ignore its name, and just think of it as the public interface
>> to the init system service management (which is init-system-agnostic).
>>
>> You can basically ignore the runlevel stuff (it's delegated to the LSB
>> headers for sysv-rc, so only of historical interest). It basically
>> has four actions:
>> - defaults (add [with default runlevels])
>> - remove
>> - enable
>> - disable
>> So long as you cater for this, that's sufficient. With sysv-rc,
>> insserv processes the LSB headers for runlevel information and
>> dependencies; you change them there if you want to adjust them. epoch
>> can deal with that side of things however it sees fit (it's entirely
>> an implementation detail)
>>
>
> Thanks a lot Roger for your explanation.
>
> However, I still fail understand how to implement what you explained
> without changing anything on any other packages that have daemons to be
> managed by epoch. As I mentioned on one of my emails on this thread, the
> implementation has always been to include the files specific to the init
> systems into those packages. I still can not believe that this is the
> only way. Could we not have some kind of man-in-the-middle (I believe
> the programming term is API) to be used by all packages including the
> init systems that are totally independent, to talk to each other? I am
> sorry for those silly questions, but it would be great if you could
> explains the reasons why the implementation is always like that and the
> impacts if we would divert from that.
>
> I think for me that would also explain why there is no other way to
> avoid lock-in to systemd rather than forking Debian.

Historically, every new init system (or at least, new in Debian) has
strived for some degree of compatibility with sysvinit. Both upstart
and systemd will run traditional init.d scripts, and both plug into
update-rc.d to act on changes. Had we been able to go forward with
openrc support, we would have done the same there as well (I think
patches were made for this already). upstart didn't make use of the LSB
dependencies; systemd does to an extent but in practice it doesn't work
as well as it could.

In short, if epoch can't make use of the existing init scripts provided
by all packages, it's going to have a very big struggle. It absolutely
must be a drop-in replacement for the existing system in order to be
viable. There's over two decades of accumulated knowledge in the
existing scripts (not for all daemons, but particularly initscripts and
other core scripts). Witness the large number of regressions and now
unsupported configurations with the systemd switch--this is largely due
to dropping all that without reimplementing it properly. Now systemd
will use its own configuration files preferentially, and use the init
scripts where necessary, so from its POV it's a relatively smooth
transition where individual packages can add systemd units relatively
easily. epoch much consider doing something similar, since having flag
day where every package adopts a brand new format is simply logistically
impractical.


Regards,
Roger