Hi! On Wed, 2015-11-04 at 10:59:19 +0100, Patrick Schönfeld wrote: > Package: dpkg > Severity: wishlist > > as of today services a started once they are installed. This is a problem > in some cases, e.g. when installing and configuring a service via puppet > and/or in preparation for a HA setup. > > We had a lot of discussions around this design decision in the past and I > do not want to restart that. Instead I'd like to propose a feature to > opt-out from automatic service startup by introdocution of a new dpkg > option, e.g. Dpkg::StartServices with a truthy default. > > RATIONALE: > By adding a configuration option for this, we allow the administrator of a > Debian system to decide if services are started after installation or not. > > It is superior to adding a command line switch only, since it allows the > admin to set this permanent and system-wide (with all its disadvantages) or > on a per-installation base (which would be suitable to be used by > configuration management systems).
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)? > 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. But perhaps I'm not fully understanding your proposal? Thanks, Guillem
