> Most Debian systems will not have this script as the need for a policy layer is not very common. Most people using chroot jails just need an one-line script which returns an exit status of 101 as the jailed /usr/sbin/policy-rc.d script.
I think, however, that the point that the parent comment was trying to make was that it'd be convenient if this was a switch to apt-get. After all, if you are just looking to install one additional daemon on a running system, it'd be a whole lot easier if you could:
# apt-get install --no-start-daemon example
than to have to activate a policy script which you might forget to remove or deactivate.
However, in the file I mentioned above, the next line says:
> The /usr/sbin/policy-rc.d file must be managed through the alternatives system (/usr/sbin/update-alternatives) by any packages providing it.
So maybe one solution is to create your own script to manage it.
In fact, your script could even be a wrapper for apt-get. To be totally transparent in day-to-day use, you could then make apt-get be an alias for your wrapper script.
> POLICY-RC.D Policy layer (/usr/sbin/policy-rc.d) interface:
> Most Debian systems will not have this script as the need for a policy layer is not very common. Most people using chroot jails just need an one-line script which returns an exit status of 101 as the jailed /usr/sbin/policy-rc.d script.
I think, however, that the point that the parent comment was trying to make was that it'd be convenient if this was a switch to apt-get. After all, if you are just looking to install one additional daemon on a running system, it'd be a whole lot easier if you could:
# apt-get install --no-start-daemon example
than to have to activate a policy script which you might forget to remove or deactivate.
However, in the file I mentioned above, the next line says:
> The /usr/sbin/policy-rc.d file must be managed through the alternatives system (/usr/sbin/update-alternatives) by any packages providing it.
So maybe one solution is to create your own script to manage it.
In fact, your script could even be a wrapper for apt-get. To be totally transparent in day-to-day use, you could then make apt-get be an alias for your wrapper script.
Your wrapper then:
1. Activates the policy.
2. Calls the real apt-get.
3. Deactivates the policy.