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.

> Just as a side note about epoch in general. It looks like it's using
> numerical dependencies. While this does in one sense give control
> over ordering to the admin, in reality numerical ordering is a real
> PITA. We spent half a decade moving sysv-rc away from that to a
> dependency-based system due to all the horrible problems numerical
> ordering caused. Everything the numerical ordering does can be
> expressed more descriptively via dependencies as in the LSB headers,
> since numbers on their own don't describe why it's at that particular
> position in relation to the rest, and you quickly run out of "gaps" in
> the numbering system as you add more services. The dependency
> information in practice gives more control to the admin; so long as
> it's possible to dump the ordered list so you can see how it gets the
> list.
>
>
> Regards,
> Roger
>

Cheers,

Anto