]] Ian Jackson
> Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts
> fail to restart a service"):
[...]
> > This means that failure to start a daemon should generally not cause the
> > postinst to fail.
>
> ... I disagree with that. I think that in the usual case, if the
> daemon is broken, and the package's purpose is to provide that daemon
> service, then the package probably isn't providing its API.
I don't think dpkg relationships are a good fit for expressing those
kinds of statements. They are not about in-memory and process state
management, they're about what's on disk.
[...]
> Also:
>
> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in the configured state,
> > so dpkg dependencies are not useful for expressing "this service must be
> > running".
>
> I disagree with this.
>
> dpkg dependencies are not just about what sets of packages can be
> coinstalled. They also imply sequencing of package setup. And since
> starting daemons is part of package setup, dpkg dependencies imply a
> sequencing of daemon startup.
If you include the word «attempted» there, I might agree. policy-rc.d
for instance enters the picture here. Blacklisting in the init system
does as well, probably others too. The landscape is pretty crowded with
actors.
> That is actually necessary in the case where the startup of daemon B
> can only successfully completed if daemon A is up,
That's the job of the init system's dependency resolution mechanisms,
not dpkg's. dpkg does not have information about what is running and so
can't do this. Ordering is also separate from dependencies, at least
for some init systems.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
