---------- Forwarded message ---------- From: Patrick Schönfeld <patrick.schoenf...@gmail.com> Date: 2015-11-04 18:27 GMT+01:00 Subject: Re: Bug#804018: dpkg: provide options to avoid service startup on package installation To: Holger Levsen <hol...@layer-acht.org>
Hi, thanks for thinking about my proposal and commenting on it. 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. 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). Maybe it helps understanding my proposal, if I describe a use case: Let's say I'd like to install serviceX, which shall be managed by pacemaker. Since pacemaker will manage the runtime status of the service this means to install, disable (and currently) stop the service (which is a hack in declarative configuration management systems since there is no state to describe "install package with service disabled"). 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. 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. > > 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? Best Regards, Patrick Schönfeld
