Re: Bug#500176: This bug is still around and release-critical
On 2008-10-05, Pierre Habouzit <firstname.lastname@example.org> wrote:
> FWIW this problem is found in many other cases: see lighttpd with
> apache2 installed, or caudium or any other http daemon, and none of them
> has a bug about it, it's unfair to mark it as RC.
also note that this bug isn't symmetric with bind9, which
opportunistically attempts to bind every ip address on the system.
(in fact, it will periodically re-scan the interfaces list and attempt
to bind new ip address on the system; see the 'interface-interval'
setting.) if no addresses can be bound, named will still start.
i just installed bind9 on a test system running unbound and found that
the bind9 package installed rc?.d symlinks at the S15 level, which
causes it to start sooner than unbound at S85. after a reboot, unbound
will fail to start since bind9 has bound the ip addresses unbound uses.
(by default, unbound only tries to bind 127.0.0.1 and ::1). so
installation in the order (unbound, bind9) will succeed and both daemons
will start, but at boot the startup order (bind9, unbound) will fail.
> I believe the problem here is somehow very generic, and that using a
> virtual package like proposed in the bug report (#500176) doesn't scale
> well. Especially for dns daemons. Packaging two of them myself (nsd3
> that is an authoritative server only, and pdnsd that is a caching daemon
> only) I can tell the virtual package solution would be a mess: I _want_
> to be able to use nsd3 _and_ pdnsd on the same machine (I actually do
> since the former binds to the external IPs only and pdnsd to 127.0.0.1)
> but by default nsd3 listens on 0.0.0.0 and you can't apt-get install
> pdnsd if you haven't configured nsd3 properly first. And you cannot make
> both conflict, both should work fine.
yes, virtual packages are a nonstarter because of all the strange ways
dns can be combined on the same machine (see, e.g., the dnsproxy