Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=668153 --- Comment #9 from Roy Marples <roy@xxxxxxxxxxxx> 2011-02-07 13:32:26 EST --- (In reply to comment #3) > Second, the fact that all resolvconf implementations use the network interface > names as an ordering and tracking mechanism is completely wrong, since what you > want to do for priority here has nothing to do with the interface name, and > everything to do with the network you're connecting to, which is independent of > the interface name that's connecting to that network. Plus interface names can > be anything. Essentially, using a resolvconf framework does not play well with > an actual dynamic system. I think I answered that above. > Third, resolvconf simply cannot handle bad ordering, if a program crashes or > otherwise does not remove its configuration. This is correct, but hardly earth shattering either. The limitation of 3 libc resolvers is of note, but then a more powerful local resolver such as unbound, dnsmasq or bind can be configured for a much larger number and probably has better failover. openresolv can configure these quite easily with minimal user configuration required. Of course, I expect quality systems such as RedHat not to be shipping programs that crash or fail to function correctly which makes this a non issue ;) > So I'm kind of curious what the motivations for this are, and what problems a > resolvconf implementation would actually solve? resolvconf provides a common ground for many things updating resolv.conf(5) and optionally configuring more powerful local resolvers. openresolv is such an implementation and requires a POSIX userland and shell, ie no external 3rd party libraries. You, on the other hand, maintain NetworkManager, which granted can maintain resolv.conf(5) in a similar vain so it's natural that you are hostile towards it. However NetworkManager requires many things which are only found on Linux based systems and requires GTK+ as well as a few others. And last I checked it had no provision for local resolvers other than libc. At this point you may be wondering "why local resolvers?" Well, the answer is quite simple - openresolv has an extension to mark the interface resolv.conf as private. So consider this eth0: search foo.com nameserver 1.2.3.4 vpn0: (marked private) search bar.org nameserver 1.2.3.5 openresolv would configure the local resolver (where possible) to send query for bar.org to 1.2.3.5 and any other query to 1.2.3.4 Very handy for work VPN systems. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review