On Wed, 2008-08-27 at 06:34 +0100, Roy Marples wrote: > On Tue, 2008-08-26 at 22:20 -0400, Dan Williams wrote: > > On Wed, 2008-08-27 at 03:49 +0200, Michael Biebl wrote: > > > Roy Marples wrote: > > > > On Sun, 2008-08-24 at 01:01 +0200, Alexander Sack wrote: > > > > > > >> For the domain/search tweakage: I feel unsure about this (though I kept > > > >> this part of your patch untouched for now). This is quite a specific > > > >> feature you want to implicitly entrench here. Maybe we can push > > > >> that back until we know if and how we want to implement such a > > > >> feature? > > > > > > > > There's no real need to push it back. > > > > NM currently folds domain into searches, so there's no need to actually > > > > use domain at all. > > > > > > Hi Roy, > > > > > > I agree with Alex here. > > > Could you please split up the patch into two, so we can address those > > > two issues separately. > > > I think the resolvconf part is fine. > > > Dan, if you are ok with it also, I'd be going to commit this, unless you > > > beat me to it ;-) > > > > It looks OK, except for one change. Not sure where we left the > > conversation last, but I'm not sure if just because resolvconf is > > installed means that it's actually being used. Most of the time you can > > have a package installed, but you don't have to enable it. For the > > moment, I'd suggest either (1) #ifdef-ing the resolvconf specific stuff > > with #ifdef DEBIAN, or (2) adding a configure switch for > > --with-resolv-conf=yes which would #define USE_RESOLVCONF, and then > > protect the resolvconf stuff with #ifdef USE_RESOLVCONF. > > Would you like the path hardcoded instead of iterating through PATH at > runtime?
I don't really care whether it's searched for or hardcoded, but hardcoding sounds a bit better to me at the moment. Configure-time --with-resolvconf=/path/to/resolvconf would be my preference for now, since it allows distros and users to know exactly where NM will look for the binary. Either that or put together a short list of paths (/usr/bin, /usr/local/bin, /usr/sbin, /usr/local/sbin, etc) to look in. I think there's just too many games things can play with PATH that will screw us up here. > USE_RESOLVCONF would be better as there are implementation on systems > other than Debian ;) Yep, fine by me. > > > > > For the domain/search changes, I'd like to take a separate look. > > > > Agreed, though I think the behavior change here is just to make searches > > > domain, while right now it's the other way around. I'm not exactly > > sure whether that's the right thing to do but we should probably be > > following the current standards and doing backwards-compat as the > > fallback unless there's a major problem. > > That's fair enough. Still, I don't know of a single libc implemention > that allows both domain and searches in resolv.conf Right, they are mutually exclusive an NM isn't honoring that. My comment was more about the code in rewrite_resolv_conf() that sets searches from the domains list when there isn't anything in the searches list. But here's how it _should_ be going: 1) Kill the 'domain' list in NMIP4Config 2) Split DHCP-provided "domain_search" and add to NMIP4Config's searches list 3) Split DHCP-provided "domain_name" and add to NMIP4Config's searches list, ignoring duplicates that are already there from "domain_search" 4) Always write out 'searches' in resolv.conf, never write out 'domain' Sound good? That should be a separate patch to the resolvconf changes. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
