Comment 6 for bug 959037

> Please, tell me more about your setup so we can make sure we cater for this use case before release.

1) Install precise-desktop-i386.iso to some-pc.
2) Install dnsmasq. Fails to start. OK, annoying but let's see if the problem goes away after reboot.
3) Reboot. Try to `dig @some-pc ubuntu.com` from *another* PC.

Here's the problem. It *sometimes* works. The "caching resolver" implementation introduced a race condition.
So if the nm-spawned dnsmasq starts first, then the dnsmasq package is broken, and doesn't fulfill its stated goal to "provide DNS to a small network" out of the box and without manual editing of nm conffiles.
If the real dnsmasq starts first, then the "caching resolver" is broken instead.

Because of time constrains, I think that checking if [ -d /etc/dnsmasq.d ] before spawning dnsmasq from nm, would satisfy most of dnsmasq users. I don't think there are many users that want to keep the nm-spawned dnsmasq when they install the real one. Maybe something similar can be done for bind too.
In the future, maybe the "caching resolver" implementation can start using /etc/dnsmasq.d itself, along with the KVM-spawned instances too, so that people only have one dnsmasq instance instead of multiple ones?

(The reason we're using the desktop iso instead of the server one, is that we need a desktop environment in our servers for our LTSP thin clients, and because teachers work on our servers, they're not headless).