On Sun, Feb 04, 2007, Brian May wrote:
> Is it still the case that packages should not update
> /etc/nsswitch.conf as documented in bug #78110?
I don't think #78110 states that packages should not update
/etc/nsswitch.conf and #78110 has its youngest message in the previous
> The reason I ask is because libnss-mdns does just
> this (e.g. see bug #406198), and I thought this
> was a policy violation.
#406198 is about reverting the changes it does to nsswitch.conf on
removal, not about not updating nsswitch.conf, but yes, libnss-mdns
edits the conffile of another package.
Before the auto-updating, another solution was chosen which was to list
mdns in the nsswitch.conf conffile (see base-files 3.1.8) but this was
reverted due to various issues (see 3.1.10) and nsswitch.conf isn't a
conffile since 3.1.11 precisely to permit updating: see #348580.
(The issues for the reversal in 3.1.10 were:
- reference to a non-base lib in a base package
- exact configuration of mdns and place of mdns in nsswitch.conf didn't
reach a consensus)
I don't think the very special case in which libnss-mdns lies will ever
be covered by policy, and I think this is the best which can be
achieved for now. If you have proposals to automatically integrate
mdns without touching the file, it would be interesting to dicsuss them
and perhaps propose any relevant infrastructure to -- say -- the glibc
package for example.
> My personal opinion is that I consider /etc/nsswitch.conf, like
> /etc/network/interfaces, a file reserved for local administrators and
> changing the fundamental polices of the computer because some package
> the administrator never heard of before was automatically pulled into
> the upgrade process is not a good thing.
It is one way of seeing it, however you've got to see it from the other
way as well: how is it possible to integrate a new type of lookup
(mDNS) on desktop machines which want RendezVous / UPnP / mDNS to work?
People at which we target mDNS usage could be you and me, but I don't
think we want to request every current and future user of libnss-mdns
to edit nsswitch.conf before it works; we're talking about a package
installed by default on the default desktop. And even I wouldn't like
being bothered to hand-edit nsswitch.conf.
> (not to mention mdns breaks anybody who used the recommendations of a
> draft Internet standard to name local computers as documented
> already in numerous bug reports)
This is a separate issue. You can blame mDNS for not keeping backward
compatibility with existing networks using .local, but it is a fact
that wont change, and yes, it is fundamentally incompatible to mix mDNS
and regular DNS on a network which has a .local TLD.
However, please note that libnss-mdns can be pulled and should not
prevent regular DNS from working on such a network: libnss-mdns
basically forwards all its mDNS queries to avahi-daemon and
avahi-daemon will disable itself when it detects a .local SOA. This
means mDNS wont work on such networks, but DNS should continue working
as it was.
Loïc Minier <firstname.lastname@example.org>