Do we need a read-rc.d?
Packages that need to change their init script execution order during an update have a problem: sysv-rc's and file-rc's abstraction layer (which is access through update-rc.d and invoke-rc.d) doesn't offer read access. Hence, it is impossible to see whether the execution order has been locally modified without interfering with the internal mechanisms of the appropriate package.
This is not only error-prone, but it makes the introduction of a third runlevel and execution order management package next to impossible. This issue, IMO, needs to be addressed in Debian.
This is a message I wrote to the maintainers of sysv-rc and file-rc to solve this issue:
the issue I am bothering you is that the abstraction layer we provide to run level configuration (update-rc.d, invoke-rc.d) is missing a feature to read out the current configuration.
This might be needed in cases where a package has to migrate to a different start ordering after it has been installed. update-rc.d is a no-op if rc.d has already been configured for the init script in question, and first removing the startup config and then setting it again will overwrite user configuration.
So, the init script needs a way to see which configuration is already in place to be able to decide whether the package is still at the default or has been locally changed. That functionality is missing in the abstraction layer.
Most packages which have to do so directly read and modify rc.d symlinks, which breaks file-rc on these systems.
Would it be possible to have a read-rc.d implemented in both sysv-rc and file-rc and then incorporated into policy?
May I ask for your opinions?
Miquel replied to the message and said that this would probably be update-rc.d -l, but that he would not be making this change for etch since the startup scheme is going to be overhauled anyway.
Comments
Display comments as Linear | Threaded