[sysvinit-devel] Re: Teach insserv to handle virtual facility provides directly in init.d scripts?

[Petter Reinholdtsen]

[Werner Fink]
> Hmmm ... the problem with this approach is e.g. if network script
> is not installed no $network will be provided even if other
> scripts refer to $network.

That sound like a good idea to me.  If some script require $network
and no script provide it, it is a fatal error and should be addressed,
right?  Those scripts what only want to start after the network is up
only when the network script is around would use should-start:
$network, and still work, right?

> Also it will move the responsibility from the insserv maintainer
> forward to the individual package maintainers including foreign
> package maintainers which may (in my experience;) increase the
> numbers of potential problems.

Well, that is already in place by supporting /etc/insserv.conf.d/, and
I believe it is important in Debian to be able to delegate the
definitions of virtual facilities to the individual package
maintainers to make sure the boot system scale.

> For optional contributions for a system facility we could do
> somewthing like
> 
> # Provides: dnsmasq
> # X-Contribute: $named 
> 
> that could be a way to do this, and it would allow to use
> nick names for a Provide.

This seem to me to be equivalent to 

  # Provides: dnsmasq $named

How would the expressed relation be different by inventing a new
header type for virtual facility provides?

Happy hacking,
-- 
Petter Reinholdtsen