I'll review it

Does this work exactly like resolvconf?  We've had no end of problems with people using resolvconf with NetworkManager, and it's usually fixed by just removing resolvconf entirely.  Ubuntu doesn't even install resolvconf by default anymore.

How is the final resolv.conf generated and what algorithm defines the priority of nameservers in the final file?

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.

Third, resolvconf simply cannot handle bad ordering, if a program crashes or otherwise does not remove its configuration.

So I'm kind of curious what the motivations for this are, and what problems a resolvconf implementation would actually solve?

(In reply to comment #2)
> Does this work exactly like resolvconf?
I have no idea, truly said, I have never used resolvconf.

>  We've had no end of problems with
> people using resolvconf with NetworkManager, and it's usually fixed by just
> removing resolvconf entirely.
I hadn't been aware of this.

>  Ubuntu doesn't even install resolvconf by default anymore.
I know that debian doesn't have resolvconf or openresolv (in unstable) installed by default.
And I have no intention pushing openresolv to default install in Fedora.

> How is the final resolv.conf generated and what algorithm defines the priority
> of nameservers in the final file?
I don't know but will try to ask upstream.

(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.
> 
> Third, resolvconf simply cannot handle bad ordering, if a program crashes or
> otherwise does not remove its configuration.
> 
> So I'm kind of curious what the motivations for this are, and what problems a
> resolvconf implementation would actually solve?
Motivations are described in bug Description.
My own is bug #551962.
I don't expect that anybody using NM will use openresolv.
I have been aiming at those not using NM but e.g. DHCPv4+DHCPv6 dhclient.

I have been testing it slightly and it seemed to work pretty well (after modifying initscripts and switching selinux off :-).
I also build NM with --with-resolvconf=yes and tried with NM.

When I had NM_MANAGED eth0 a NOT NM_MANAGED eth1 (dual stack dhclient),
'resolvconf -l' was showing:

# resolv.conf from dhclient.v4.eth1
nameserver 192.168.1.132

# resolv.conf from dhclient.v6.eth1
nameserver 3ffe:501:ffff:1::131

# resolv.conf from NetworkManager
# Generated by NetworkManager
nameserver 192.168.0.1

and the resulting resolv.conf:
# Generated by resolvconf
nameserver 192.168.0.1
nameserver 192.168.1.132
nameserver 3ffe:501:ffff:1::131

But thanks for sharing your experience,
I'll try to discuss it with upstream first.

Yes, the current situation with the /etc/resolv.conf filling is a mess. Also there are a lot of packages which doesn almost the same things, so adding another one is not an issue.

I personally have no objections against openresolv, so (keeping in mind that it neither conflicts with NetworkManager nor pretends to be installed by default) here is my

REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

- rpmlint is NOT silent
work ~: rpmlint Desktop/openresolv-3.4.1-1.fc15.*
openresolv.noarch: W: spelling-error Summary(en_US) resolv -> resolve, resole, resold
openresolv.noarch: W: spelling-error %description -l en_US resolv -> resolve, resole, resold

^^^ False positive.

openresolv.noarch: W: manual-page-warning /usr/share/man/man8/resolvconf.8.gz 3375: bad character definition
openresolv.noarch: W: manual-page-warning /usr/share/man/man8/resolvconf.8.gz 3379: warning: macro `\}' not defined
openresolv.noarch: W: manual-page-warning /usr/share/man/man5/resolvconf.conf.5.gz 3375: bad character definition
openresolv.noarch: W: manual-page-warning /usr/share/man/man5/resolvconf.conf.5.gz 3379: warning: macro `\}' not defined

^^^ I failed to find what caused this message, but I'm suspection that it is triggered by configuration snippets, containing curly brackets. I'm not sure whether it's a issue or not.

openresolv.src: W: spelling-error Summary(en_US) resolv -> resolve, resole, resold
openresolv.src: W: spelling-error %description -l en_US resolv -> resolve, resole, resold
openresolv.src: W: spelling-error %description -l en_US dnsmasq -> dismast, kinsman, desman
openresolv.src: W: spelling-error %description -l en_US resolvconf -> resolvable, resolved, resolve

^^^ False positive.

openresolv.src: W: strange-permission openresolv-3.4.1.tar.bz2 0755L
openresolv.src: W: strange-permission openresolv-service-status-quiet.patch 0755L
openresolv.src: W: strange-permission openresolv.spec 0755L

^^^ This should be fixed as well (easyfix).

2 packages and 0 specfiles checked; 0 errors, 13 warnings.
work ~: 


+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (BSD).
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The package successfully compiles and builds into binary rpms on at least one primary architecture. Koji scratchbuild for F-15:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2718940

+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
0 No shared library files in some of the dynamic linker's default paths.
+ The package does NOT bundle copies of system libraries.
0 The package is not designed to be relocatable.

- The package MUST own all directories that it creates. Please, mark explicitly %{_libexecdir}/resolvconf as %dir in the %files section.

+ The package does not list a file more than once in the spec file's %files listings.

+/- Permissions on files are set properly. Just drop executable permissions from original sources (spec-file, patch and tarball).

0 The package DOESN'T have a %clean section, so it won't build cleanly on systems with old rpm (EL-4 and EL-5, not sure about EL-6). Beware.
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
0 No header files.
0 No static libraries.
0 No pkgconfig(.pc) files.
0 The package doesn't contain library files without a suffix (e.g. libfoo.so).
0 No devel sub-package.
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
+ All filenames in rpm packages are valid UTF-8.

Almost finished. Please, address issues, noted above, and I'll continue.

Spec URL: http://jpopelka.fedorapeople.org/openresolv.spec
SRPM URL: http://jpopelka.fedorapeople.org/openresolv-3.4.1-2.fc14.src.rpm


(In reply to comment #5)
> openresolv.noarch: W: manual-page-warning /usr/share/man/man8/resolvconf.8.gz
> 3375: bad character definition
> openresolv.noarch: W: manual-page-warning /usr/share/man/man8/resolvconf.8.gz
> 3379: warning: macro `\}' not defined
> openresolv.noarch: W: manual-page-warning
> /usr/share/man/man5/resolvconf.conf.5.gz 3375: bad character definition
> openresolv.noarch: W: manual-page-warning
> /usr/share/man/man5/resolvconf.conf.5.gz 3379: warning: macro `\}' not defined
> 
> ^^^ I failed to find what caused this message, but I'm suspection that it is
> triggered by configuration snippets, containing curly brackets. I'm not sure
> whether it's a issue or not.
Nor I am able to find out what could be wrong, but the man pages look good.
 
> openresolv.src: W: strange-permission openresolv-3.4.1.tar.bz2 0755L
> openresolv.src: W: strange-permission openresolv-service-status-quiet.patch
> 0755L
> openresolv.src: W: strange-permission openresolv.spec 0755L
> 
> ^^^ This should be fixed as well (easyfix).
Have no idea how they got there, hope it's ok now.

> - The package MUST own all directories that it creates. Please, mark explicitly
> %{_libexecdir}/resolvconf as %dir in the %files section.
Fixed.

> +/- Permissions on files are set properly. Just drop executable permissions
> from original sources (spec-file, patch and tarball).
See above.

Ok, good. I don't see any technical issues, so this package is

APPROVED.

Hi
I'm upstream for openresolv and was asked to comment here, so here I am :)

(In reply to comment #2)
> Does this work exactly like resolvconf?

As far as the user interface is concerned, they are the same as openresolv was designed as a drop in replacement for resolvconf.

>  We've had no end of problems with
> people using resolvconf with NetworkManager, and it's usually fixed by just
> removing resolvconf entirely.  Ubuntu doesn't even install resolvconf by
> default anymore.

One of my reasons for writing it :)
Good idea but poorly implemented. No doubt in the future someone will do better than me, but until then openresolv is the best at what it does.

> How is the final resolv.conf generated and what algorithm defines the priority
> of nameservers in the final file?

It's entirely user configurable and quite well documented, but the default is pretty much this
   $configured $dynamic (exclude dynamics with metrics) $metric $sorted
   $configured is a user defined list, default lo lo[0-9]*
   $dynamic default is tap[0-9]* tun[0-9]* vpn vpn[0-9]* ppp[0-9]* ippp[0-9]*
   $metric is numerically ordered and configured by the calling program
   $sorted is just that

So for example, if dhcpcd (which I am also upstream for) works on both wired and wireless interfaces the wired interface would be given a lower metric by default so openresolv would prefer this information. However, this is an extension to how resolvconf works so not much probably uses it other than dhcpcd right now.

(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.

After long hesitation whether to push openresolv or not I've chosen the second option.
reasons?:
- I've closed the original bug #551962 that had brought me to the idea of pushing openresolv to Fedora.
- I actually know only one person that would appreciate it (bug #551962, comment #3 + bug #626514, comment #4).

I'll leave the spec file uploaded so anybody interested could use it in future and continue where I stopped.
Thank you all (Roy especially) for your posted opinions.

Closing as wontfix.

And you proposed this as a solution...

Once again we kindly ignore the Prefix Delegation market.