[pkg-kde-talk] Re: kdnssd and avahi/libnss-mdns

[Anand Kumria]

So, in summary:

kdnssd should depend on:
	avahi-client, libnss-mdns
and recommend:
	avahi-daemon
and either suggest or recommend:
	zeroconf

Anand
	

On Tue, Jan 17, 2006 at 06:56:16PM +0100, Jakub Stachowski wrote:
> Dnia wtorek, 17 stycznia 2006 18:24, Lennart Poettering napisał:
> > On Wed, 18.01.06 03:23, Anand Kumria (wildfire at progsoc.org) wrote:
> > > > kdnssd needs avahi-daemon to function at all. avahi-daemon recommends
> > > > your libnss-mdns;
> > >
> > > avahi doesn't need libnss-mdns, and nor does libnss-mdns but if both are
> > > installed libnss-mdns will use avahi for caching purposes.
> > >
> > > You want to have libnss-mdns installed for applications which may not
> > > (indeed ever) link directly to avahi, e.g. telnet; that way things like
> > > 'telnet foo.local' will work.
> >
> > I don't know how kdnssd works internally, but it might *require*
> > libnss-mdns to work sensibly. Better ask Jakub Stachowski about
> > that. I'll forward this Email to him.
> 
> For discovering services it won't do too much without libnss-mdns because 
> kdnssd-avahi does not even try to resolve hostname.local address and just 
> hands it to application. Without libnssd-mdns application won't be able to 
> resolve it.
> 
> >
> > > > presumably these two packages would be a sensible core
> > > > zeroconf setup for kdnssd to depend on (right?). libnss-mdns recommends
> > > > the package 'zeroconf' as well. It runs in the background, which is
> > > > something I'd rather not have too many packages do, if they're not
> > > > critical; but libnss-mdns does recommend it... what do you suggest?
> > >
> > > well 'zeroconf' performs the link-local address allocation, which you
> > > definately need.  I have a 0.7 version that I'm testing that
> > > should address most of the current bugs against it.  I hope to have it
> > > ready to upload later this week.
> >
> > I don't think kdednssd should depend on "zeroconf". If it all, a
> > Suggest or Recommend should suffice.
> >
> > In addition I don't think that kdednssd should depend even on
> > avahi-daemon. The avahi client libraries return a proper error code
> > when no running daemon is found, so in case kdednssd becomes a hard
> > dependency of the KDE desktop and people don't like DNS-SD, they don't
> > need to install the daemon.
> 
> True. All publishing/discovery operations will just report failure and that's 
> all.
> >
> > > > Any other packages we should Depend/Suggest/Recommend? avahi-dnsconfd,
> > > > etc.? Any advice would be much appreciated.
> >
> > My suggestion is to depend on avahi-client. And suggest/recommend
> > avahi-daemon and libnss-mdns. However, since avahi-client recommends
> > avahi-daemon, and avahi-daemon in turn recommends libnss-mdns you may
> > even omit those suggest/recommend lines entirely.
> >
> > Hence i would suggest to just add a dependency to avahi-client and
> > that's it.
> >
> > (Unless Jakub says that libnss-mdns is required for avahi-kdnssd to
> > work properly, in which case you should add another hard dep on that.)
> 
> I'm not sure about Depends and Recommends policy but applications using  
> kdnssd-avahi will be really crippled without libnss-mdns - they won't be able 
> to use discovered services at all.
> 
> >
> > > > One last thing you might know about.
> > > > http://wiki.kde.org/tiki-index.php?page=Zeroconf+in+KDE states
> > > > that /etc/nsswitch.conf should have 'mdns' on the hosts line _before_
> > > > 'dns'. Yet on my system, mdns comes _after_ by default (this was added
> > > > due to bug #324954. Is this a problem?
> > >
> > > Well, I think it should be:
> > >
> > > hosts: file mdns dns
> >
> > I think it should be "file mdns4 dns". Someone should file a bug about
> > this.
> >
> > > because this prevents the local DNS from seeing queries to the '.local'
> > > zone; however it could slow things done as the NSS sub-system waits for
> > > mdns to return a response (which, from memory can take 3 seconds).
> >
> > By default, nss-mdns will only lookup services in the ".local"
> > zone. Hence this would not result in any significant delay for normal
> > (unicast DNS) name lookups.
> 
> And in my case (slow link) it helps to avoid unicast DNS questions for .local
> 
> >
> > Lennart

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"