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