dhcpcd-discuss

On 10/03/2015 14:58, Joachim Achtzehnter wrote:
>> On 09/03/2015 22:24, Joachim Achtzehnter wrote:
>>> The command line usage of Debian's resolvconf script, with which
>>> openresolv is supposedly compatible, uses the -a flag with an argument
>>> of the following format:
>>
>> Enough of the supposedly.
>> It is compatible. Prove, in the code, otherwise.
> 
> Just a few examples: The openresolv variant of the openresolv script
> does not support the --enable-updates and --disable-updates command line
> parameters,

Let me clarify - it's a drop in replacement when other programs such as
dhcpcd use it. No program would use those commands.

> the Debian version includes a maximum of three nameserver
> lines, openresolv includes more and if the important one is not among
> the first three it will be ignored by glibc's resolver and queries
> fail,

so glibc is limited.
I know of one libc implementation which allows more.
openresolv cannot know this and I fail to see how Debian aborting after
3 and openresolv just putting them there when only the first 3 work is
any different in the real world.

> the ordering is different

I would argue that thanks to udev naming scheme the default interface
ordering in Debian is broken.

dhcpcd supplies openresolv a metric which it can use to influence the
ordering for a more reliable output. For example if dhcpcd prefers the
subnet route on eth1 other eth0 it would be silly not to let dhcpcd tell
resolvconf to prefer the DNS on eth1 over eth0.

> openresolv includes both domain and search
> keywords even though they are documented as mutually exclusive.

every libc documents it as last one wins and as a said earlier, some
programs rely on domain being set regardless of search list.

>> Lastly, a colon has no special meaning in shell scripts.
>> If it did, it would be listed here:
>> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
> 
> This may be true, but ls seems to escape the colon in some of its output
> variants, although I don't remember the exact circumstance when I saw
> this. Not a big deal, but seems an unnecessary deviation.

Why should openresolv try to work around bugs in ls? Fix ls!

Roy