On Thu, 31 Jul 2008, Guido Günther wrote: > > The DESIGN behind invoke-rc.d and policy-rc.d is to help MAINTAINER SCRIPTS > > don't screw up when restarting/starting/stopping services automatically, > > either in the normal system context, or inside special chroots. > > > > They are NOT, and I repeat: **NOT** user-level interfaces. They are an > > abstraction layer for the Debian maintainer scripts, and that's it. You > > can't extend them past that without making them useless for their purpose, > > although you *could* add something like policy-rc.d to sysv-init if you > > wanted. But it must not be policy-rc.d itself. > README.invoke-rc.d currently has: > > # There is a provision for a "local initscript policy layer" (read: a call to > # /usr/sbin/policy-rc.d if this executable is present in the local system), > # which allows the local system administrator to control the behaviour of > # invoke-rc.d for every initscript id and action. It is assumed that this > # script is OPTIONAL and will by written and provided by packages other than > # the initscript system (sysvinit and file-rc packages). > > this gives at least the impression of a "user interface" in this case > the sysadmin being the user.
The user of invoke-rc.d is the package maintainer scripts. The user of policy-rc.d is invoke-rc.d. The local admin may use policy-rc.d to "tame" invoke-rc.d into doing what he wants for local policy, and that will cause maintainer script to obey it. > We might not want to use policy-rc.d as is in sysvinit of filerc during > startup but we might consider moving these policy decisions "no I don't > want this daemon at startup, yes I want that daemon reloaded after > resume" into a policy layer that is independent of the underlying init > mechanism and which can be queried by the different tools be it during > system startup/shutdown or after/before suspend to/from ram/disk. We could do that, yes. But that requires extending the current design carefully, not using it as-is. I don't even think you'd need to change much, in fact. But you should at the very least have different entry points for the packaging scripts (invoke-rc.d), initscript system (doesn't exist yet), and local admin (currently, a direct call to /etc/init.d/foo). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
