[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
