Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
]] Jonathan Nieder
> Russ Allbery wrote:
>
> > That seems like a feature, not a bug, in the case of configuration
> > installed by Debian packages such as what's cited in this part of the
> > thread. If I have a policy rule that says not to run that init script, I
> > mean it, and I don't want ifup running it anyway.
>
> It's just plain not clear to me what policy-rc.d should and should not
> be able to do. The "do nothing and pretend you did something"
> semantics, while they work ok in the context of post-installation
> scripts that may or may not start the just-configured daemon, are
> always going to feel a little weird in general because they break the
> patterns
They don't always work right in the context of postinst script either. A
fairly common request I'm hearing from people is «don't start the daemon
on initial installation (because we'll drop a configuration in place as
the next step and then start it)». policy-rc.d can stop it from being
started at all, but it can't really know whether this is the initial
installation or not. As Steve says, that's not really this bug, though.
[...]
> >> Another downside is that invoke-rc.d is Debian-specific.
> >
> > So are the network hooks under discussion.
>
> I think the former is relevant and the latter isn't. That may seem
> odd, so let me mention a couple of examples of fallout.
I'm not at all convinced invoke-rc.d is the right interface for this,
partially due to you easily ending up with cycles such as seen in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635777 where postfix
depends on network being up, but the network isn't considered up until
postfix has started.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: