Hi! On Wed, 2015-11-04 at 18:31:28 +0100, Patrick Schönfeld wrote: > 2015-11-04 13:19 GMT+01:00 Holger Levsen <hol...@layer-acht.org>: > > you are aware of > > > > echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d > > yes, I'am aware of the policy-rc.d mechanism, see my naive implementation > proposal (it's what I meant with policy.d layer - a misnomer of mine). > However, that would effect all service starts, not only the start after the > package installation, which my proposal aims at.
invoke-rc.d and policy-rc.d are precisely interfaces expected to be used only by maintainer scripts. Anything else done during run-time should be using some other interface, such as service(8) for example or an init specific one, otherwise that should be considered a bug. > Of course I could write some policy-rc.d script checking an environment > variable, blacklist or a like and set it before the package installation, > but that somehow feels like a hack, considering that this is just a > distribution decision I want to overrule as an admin (on a case-by-case > basis). In case this is a local problem where you have deployed non-maintainer scripts using invoke-rc.d, then while you fix those, you could check in policy-rc.d if you are running inside dpkg by checking if the environment variable DPKG_RUNNING_VERSION is defined (documented in dpkg(1)). > Providing a standard way to not start a certain service after package > installation seems a lot of cleaner. And that is what my proposal aims at. > Apart from that our distribution decision to start services after > installation is quiet controversial to some people anyway and my proposal > would provide a standard way for those people to opt-out from this choice. That's really what policy-rc.d is for. > 2015-11-04 14:08 GMT+01:00 Guillem Jover <guil...@debian.org>: > > This all feels very out of scope for dpkg. More so when policy-rc.d > > already supports what you seem to be asking for (as Holger also > > pointed out)? > > I don't think so, because after all its the package manager which starts > the maintainer scripts which in turn starts the service. Apart from that > it's _the_ place where I consciously choose to install a package and if I > want it to be running afterwards. And in case of configuration management > systems: the interface it communicates with. 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. :) > > > Possible implementation: > > > Per policy 9.3.3.2 have to interface with init via invoke-rc.d for > > service > > > startup. A possible (and admittedly naive) implementation which does not > > > involve changes in each and every package, could possibly just let dpkg > > > install a policy.d layer and ensure its absence on process end. Though > > some > > > sort of IPC between invoke-rc.d and dpkg that does not involve filesystem > > > modifications would probably be better. > > > > Something like this would mean encoding extremely system specific > > policy into the dpkg C codebase, when dpkg has no knowledge whatsoever > > on what is happening on maintainer scripts or how init scripts are > > invoked or managed etc. It does not feel right. > > Yeah, I admit that the implementation idea has all sorts of problems (which > is why I called it naive in the first place). > But I really think dpkg is the right place for the flag (to start services > or not), while invoke-rc.d is the tool called by the maintainer scripts and > therefore responsible for the actual doing. What's missing is the glue > between these components. > > Maybe a better implementation would be an environment variable respected by > invoke-rc.d and passed-thru by dpkg? As mentioned before and above, I still think this is the wrong way to look at this. And in principle I'm going to close this bug in a bit, if no other compelling arguments are put forward. Thanks, Guillem
