How packages should supply dependency information

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2005, Sven Mueller wrote:
> > The idea is to provide dependency information in files, and to make use
> > of the existing update-rc.d interface.
> 
> Again, in general, I would agree with you. However: One of the release
> goals for etch is to be as LSB compliant as possible. So given this

This means we support those horrible text fields for LSB packages, and do
whatever we think is the right thing in Debian packages.

So, do not feel tied to the incomplete work the LSB did at *all*.  Just try
to make sure we can convert the LSB information to something we can use (the
inverse is not needed).

Which doesn't mean we could not have in-band text fields in the initscripts.
As long as it is not a kludge, and if we have to break with LSB to get all
fields with the semantics we need, IMHO we should do just that.

I am personally for an out-of-band storage for that information, because it
gets easier to manipulate it then.  It would need to be a textfile somewhere
in /etc, preferably inside /etc/init.d, though.

We will have to write cache information and preferred path information, plus
timing information to get the most out of a dep-based parallel initscript
system anyway, so we will end up with an out-of-band storage somewhere.
Might as well put everything re. dependencies in there, so that tools never
have to touch the initscripts themselves to update the dependencies.

IMHO we really, *REALLY* have to improve update-rc.d (or whatever
superseedes it) so that it works just like diversions using dpkg-divert:
i.e.  package-level choices, and local-admin level choices which override
those.  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.

> On a side note: There are packages like mysql-server-5.0 which install
> init scripts for several daemons. In the case of mysql-server-5.0: the
> main server as well as the ndb and ndb-mgm daemons. What would you do
> about packages which install multiple daemons, each with its own init
> script?

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

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh