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)

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

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to