Hi, 2015-11-05 2:38 GMT+01:00 Guillem Jover <guil...@debian.org>: > > That's really what policy-rc.d is for. >
and I think that is not the right interface for such cases or at least it's not the best interface we can can provide for such cases. It's certainly good enough for the admin who wants to overrule our policy permanently, although letting the admin write a script for such a simple decision still feels kind of clumsy. IMHO it has probably been designed for build chroots and that's absolutely the purpose it fits best. But let's have a deeper look at the configuration management case. If they wanted to provide a way to say "install that package, but make sure that the service is not started afterwards", they could either a) Permanently install a policy-rc.d layer, letting it interface with the package install (e.g. by the env variable you said and another one set by the configuration management to tell the policy-layer which service the policy applies to) b) Install a policy-rc.d layer before each package installation, removing it afterwards c) Let each user handle installing a policy-rc.d layer either permanently or before each package installation Each of this option has several disadvantages: With a) the admin is no longer able to install another policy-rc.d script, apart from that it's a quiet invasive from a configuration management system to put a script in place that is permanently interfered with for every service that is ever started. With b) the door is widely opened for all kind of trouble, e.g. leaving mess around after package installation. Sure there can be put safety measures into place to avoid that, but overall it increases complexicity - for a Debian specific solution, since other distributions just don't start services after installation. With c) everything applies which applies to b), additionally each user has to implement this himselves and need to workaround the fact, that the configuration management system is not aware of his implementation. Thats where we are today: Some people employ exec-handlers to kill the service after install, some put a policy-rc.d layer in place. All of these solutions have in common that they workaround a decision that we as a project have made (to provide "default" configurations for services and start them after package installations), which is fine in some cases (e.g. software I *want* to be running after installation like sshd) and not so fine in others (installing services I want to manage via a clusterstack for example). Feels somewhat like giving the user some nails, but expect him to build the hammer on his own. > dpkg has no idea nor control over what happens inside maintainer scripts, > those are exclusively under the package domain. Starting services is > just one of the actions that can be done there, if any other policy > would require making dpkg aware of it, then dpkg would suddenly have > to know about tons of things it has no control over. But that place > already exists anyway, per above. :) > > And it does not have to have an idea what happens inside maintainer scripts. But since it's responsible for installation of those packages, it is also responsible for providing the environment in which the maintainer scripts run. Seems absolutely legit to restrict what the maintainer scripts are allowed to do, even if that restriction is soft, in a way that could be ignored by the maintainer scripts. In that specific case, however, we absolutely do have control over what happens. We have a policy in place that maintainer scripts have to interface with invoke-rc.d, so if we'd decide on a flag, we could very well set it in dpkg and let invoke-rc.d respect it. It would be cheap and solving a problem in a way that other tools (like configuration management) can rely on. And if the maintainer script does not run an init script at all, this flag does no harm either. Best Regards, Patrick
