How packages should supply dependency information

[Petter Reinholdtsen]

[Henrique de Moraes Holschuh]
> That way, we will be able to move a initscript in the dep chain
> without fighting the local admin when we are allowed to.  What we
> have right now is just too limiting.

There seem to be a misunderstanding over what we have no.  The only
package in Debian processing the LSB init.d headers at the moment is
insserv.  It is able to reorder the boot sequence based on the
dependency information present.  It will look in /etc/init.d/<script>,
/usr/share/insserv/override/<script> (if the previous one is missing)
and /etc/insserv/override/<script> for dependency information,
allowing the local admin to provide dependency overrides outside the
init.d scripts (in /etc/insserv/overrides/<script>) if he isn't happy
with the default dependencies provided by the package maintainer.

The insserv package is not perfect, but it is a step in the right
direction, and give an indication on how to use the dependency
information.

> Whatever we do must have initscript-level granularity.
> Package-level granularity is simply not good enough.

Yes, that is correct.

I fail to see why having the dependency information in the init.d
script is bad design, as long as it is possible to read that
information from other sources as well when the need to override it
locally is present. :)