Hi guys,
Currently we use the BIND code base in two packages: - dnsutils from [core] provides basic DNS query tools; - bind from [extra] is the actual name server.
With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost!
That mostly means two things: - We cannot keep splitting dnsutils and bind anymore. - I do not want to maintain these packages any further.
We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc.
So I suggest: - Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases. - We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Comments or suggestions are welcome.
Cheers.
On Sat, Mar 09, 2013 at 01:27:42PM +1100, Gaetan Bisson wrote:
Hi guys,
Currently we use the BIND code base in two packages:
- dnsutils from [core] provides basic DNS query tools;
- bind from [extra] is the actual name server.
With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost!
That mostly means two things:
- We cannot keep splitting dnsutils and bind anymore.
- I do not want to maintain these packages any further.
We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc.
So I suggest:
- Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases.
- We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Comments or suggestions are welcome.
Cheers.
-- Gaetan
Just a small question, will we provide migration paths for people using bind as nameserver in their internal networks ?
[2013-03-09 20:01:22 +0100] Ike Devolder:
Just a small question, will we provide migration paths for people using bind as nameserver in their internal networks ?
Do you mean as a caching name server? For this, just install unbound, run the daemon service, and you're good to put 127.0.0.1 in resolv.conf.
The alternative to bind as an authoritative name server is nsd. The zone files it uses are the same as bind's, but the daemon configuration is slightly different. It's really not hard though, but if you can't figure it out Google will find migration scripts, etc. Of course, anybody is free to maintain bind in any repo or the AUR - it just won't be me.
Cheers.
On Mon, Mar 11, 2013 at 07:05:42PM +1100, Gaetan Bisson wrote:
[2013-03-09 20:01:22 +0100] Ike Devolder:
Just a small question, will we provide migration paths for people using bind as nameserver in their internal networks ?
Do you mean as a caching name server? For this, just install unbound, run the daemon service, and you're good to put 127.0.0.1 in resolv.conf.
The alternative to bind as an authoritative name server is nsd. The zone files it uses are the same as bind's, but the daemon configuration is slightly different. It's really not hard though, but if you can't figure it out Google will find migration scripts, etc. Of course, anybody is free to maintain bind in any repo or the AUR - it just won't be me.
Cheers.
-- Gaetan
i was just wondering for user convenience, i don't really care which nameserver i can and must use in my local network.
[2013-03-09 13:27:42 +1100] Gaetan Bisson:
- We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
I would like to post the following announcement. Comments are welcome.
Deprecation of bind and dnsutils
The direction BIND has taken with its recent BIND10 release [makes it impossible](https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024588.ht...) for us to keep relying on it. Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
We strongly suggest you migrate your own software to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/) too, and replace [bind](https://www.archlinux.org/packages/extra/x86_64/bind/); with ldns-based alternatives:
- the [unbound](https://www.archlinux.org/packages/community/x86_64/unbound/) resolving server (see [wiki](https://wiki.archlinux.org/index.php/Unbound)); - the [nsd](https://www.archlinux.org/packages/community/x86_64/nsd/) authoritative server (see [wiki](https://wiki.archlinux.org/index.php/Nsd)).
The deprecated packages [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) and [bind](https://www.archlinux.org/packages/extra/x86_64/bind/) will soon be dropped to the AUR.
On Tue, Mar 19, 2013 at 10:50 PM, Gaetan Bisson bisson@archlinux.org wrote:
[2013-03-09 13:27:42 +1100] Gaetan Bisson:
- We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
I would like to post the following announcement. Comments are welcome.
Deprecation of bind and dnsutils
The direction BIND has taken with its recent BIND10 release [makes it impossible](https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024588.ht...) for us to keep relying on it. Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
We strongly suggest you migrate your own software to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/) too, and replace [bind](https://www.archlinux.org/packages/extra/x86_64/bind/); with ldns-based alternatives:
- the [unbound](https://www.archlinux.org/packages/community/x86_64/unbound/) resolving server (see [wiki](https://wiki.archlinux.org/index.php/Unbound));
- the [nsd](https://www.archlinux.org/packages/community/x86_64/nsd/) authoritative server (see [wiki](https://wiki.archlinux.org/index.php/Nsd)).
The deprecated packages [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) and [bind](https://www.archlinux.org/packages/extra/x86_64/bind/) will soon be dropped to the AUR.
This will have add 4 soon-to-be-dead links to packages in a news item, which doesn't seem like a great idea. It also links exclusively to one architecture. I would not include a single link to anything under /packages/, whether these are new or old- you never know what the landscape will look like in 6 months. Instead, just use the standard `pkgname` or whatever syntax and people will be smart enough to search for it.
Outside of that, the rest of the text looks good to me.
-Dan
[2013-03-19 22:57:31 -0500] Dan McGee:
This will have add 4 soon-to-be-dead links to packages in a news item, which doesn't seem like a great idea. It also links exclusively to one architecture. I would not include a single link to anything under /packages/, whether these are new or old- you never know what the landscape will look like in 6 months. Instead, just use the standard `pkgname` or whatever syntax and people will be smart enough to search for it.
Right. Here's the updated version.
Deprecation of bind and dnsutils
The direction BIND has taken with its recent BIND10 release [makes it impossible](https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024588.ht...) for us to keep relying on it. Consequently, official packages using `dnsutils` were migrated to `ldns`, a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
We strongly suggest you migrate your own software to `ldns` too, and replace `bind` with ldns-based alternatives:
- the `unbound` resolving server (see [wiki](https://wiki.archlinux.org/index.php/Unbound)); - the `nsd` authoritative server (see [wiki](https://wiki.archlinux.org/index.php/Nsd)).
The deprecated packages (`dnsutils` and `bind`) will soon be dropped to the AUR.
[2013-03-20 15:14:19 +1100] Gaetan Bisson:
Deprecation of bind and dnsutils
I've just moved dnsutils to [extra] and orphaned it as well as bind. This announcement is postponed as long as somebody can manage to keep BIND alive...
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
On 03/20/2013 11:05 AM, Thomas Bächler wrote:
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
host and dig are tools that I use every day and they are the standard.
i don't see why they should be dropped just because bind (as in the server) doesn't suite you well now.
why cannot we keep the tools?
On Wednesday, March 20, 2013 11:07:34 Ionut Biru wrote:
On 03/20/2013 11:05 AM, Thomas Bächler wrote:
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
host and dig are tools that I use every day and they are the standard.
i don't see why they should be dropped just because bind (as in the server) doesn't suite you well now.
why cannot we keep the tools?
I'd +1 for keeping dnsutils 9 as is in the repos for now, if my vote counts :P
Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
[2013-03-20 17:11:19 +0800] Felix Yan:
I'd +1 for keeping dnsutils 9 as is in the repos for now, if my vote counts :P
There's no vote and "+1"'s are as meaningless as they always were. Either you have new arguments to contribute to the discussion or you don't.
On 20/03/13 19:07, Ionut Biru wrote:
On 03/20/2013 11:05 AM, Thomas Bächler wrote:
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
host and dig are tools that I use every day and they are the standard.
Can't we symlink drill -> dig etc?
i don't see why they should be dropped just because bind (as in the server) doesn't suite you well now.
At the minimum, the new deps mean dnsutils needs dropped from [core].
why cannot we keep the tools?
Are volunteering to maintain it? As the original email said:
On 09/03/13 12:27, Gaetan Bisson wrote:
- We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Allan
On Wednesday, March 20, 2013 19:21:16 Allan McRae wrote:
On 20/03/13 19:07, Ionut Biru wrote:
On 03/20/2013 11:05 AM, Thomas Bächler wrote:
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
host and dig are tools that I use every day and they are the standard.
Can't we symlink drill -> dig etc?
Not really, it behaves not the same when you want +trace +short, etc. (I used $(dig +short ...) a lot in my own scripts)
Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
[2013-03-20 11:07:34 +0200] Ionut Biru:
host and dig are tools that I use every day and they are the standard.
i don't see why they should be dropped just because bind (as in the server) doesn't suite you well now.
why cannot we keep the tools?
My original message will answer all your questions.
If after reading my arguments you still want to cling to the sinking ship BIND has become, feel free to adopt bind and dnsutils. If nobody adopts them, I'll proceed as planned.
[2013-03-20 10:05:17 +0100] Thomas Bächler:
I imagine *everyone* expects the 'host' command to exist.
I don't think most people do DNS queries by hand.
And those who do will find `drill` is superior to `host`; the output format is different (it's modeled after `dig`) but so what? As we proved by porting our packages to ldns, the migration is quite trivial.
Am 20.03.2013 10:16, schrieb Gaetan Bisson:
[2013-03-20 10:05:17 +0100] Thomas Bächler:
I imagine *everyone* expects the 'host' command to exist.
I don't think most people do DNS queries by hand.
Really? I do it often enough.
And those who do will find `drill` is superior to `host`; the output format is different (it's modeled after `dig`) but so what?
So, drill will give me a page full of useless text instead of simply giving an IP, like host does. I always found dig's output to be way more than I ever wanted, unless in very special situations.
[2013-03-20 10:25:33 +0100] Thomas Bächler:
So, drill will give me a page full of useless text instead of simply giving an IP, like host does. I always found dig's output to be way more than I ever wanted, unless in very special situations.
Alright; you can: - write a three-line drill wrapper to recreate the output of host; - adopt dnsutils and have fun with BIND.
Am 20.03.2013 10:32, schrieb Gaetan Bisson:
[2013-03-20 10:25:33 +0100] Thomas Bächler:
So, drill will give me a page full of useless text instead of simply giving an IP, like host does. I always found dig's output to be way more than I ever wanted, unless in very special situations.
Alright; you can:
- write a three-line drill wrapper to recreate the output of host;
- adopt dnsutils and have fun with BIND.
The first option makes more sense.
On Wed, Mar 20, 2013 at 4:35 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 20.03.2013 10:32, schrieb Gaetan Bisson:
[2013-03-20 10:25:33 +0100] Thomas Bächler:
So, drill will give me a page full of useless text instead of simply giving an IP, like host does. I always found dig's output to be way more than I ever wanted, unless in very special situations.
Alright; you can:
- write a three-line drill wrapper to recreate the output of host;
- adopt dnsutils and have fun with BIND.
The first option makes more sense.
host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling?
-Dan
On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee dpmcgee@gmail.com wrote:
host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling?
util-linux does not. coreutils and iputils provide 'host', but both are incompatible with the legacy one (and, iirc, each other).
-t
Am 20.03.2013 14:42, schrieb Tom Gundersen:
On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee dpmcgee@gmail.com wrote:
host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling?
util-linux does not. coreutils and iputils provide 'host', but both are incompatible with the legacy one (and, iirc, each other).
-t
They are certainly better than using either 'drill' or 'getent hosts/ahosts', all of which either return too much (drill and getent ahosts) or too few (getent hosts) information.
On Wed, Mar 20, 2013 at 3:03 PM, Thomas Bächler thomas@archlinux.org wrote:
Am 20.03.2013 14:42, schrieb Tom Gundersen:
On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee dpmcgee@gmail.com wrote:
host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling?
util-linux does not. coreutils and iputils provide 'host', but both are incompatible with the legacy one (and, iirc, each other).
-t
They are certainly better than using either 'drill' or 'getent hosts/ahosts', all of which either return too much (drill and getent ahosts) or too few (getent hosts) information.
If we can live with the incompatibility, I'd be in favor of moving 'host' to coreutils, but we have tried that before and people were not happy...
-t
On Wed, Mar 20, 2013 at 08:34:46AM -0500, Dan McGee wrote:
On Wed, Mar 20, 2013 at 4:35 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 20.03.2013 10:32, schrieb Gaetan Bisson:
[2013-03-20 10:25:33 +0100] Thomas Bächler:
So, drill will give me a page full of useless text instead of simply giving an IP, like host does. I always found dig's output to be way more than I ever wanted, unless in very special situations.
Alright; you can:
- write a three-line drill wrapper to recreate the output of host;
- adopt dnsutils and have fun with BIND.
The first option makes more sense.
host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling?
-Dan
glibc ships getent, which can be used to do DNS lookups (getent hosts www.google.com). That said, I don't expect people to know this offhand as an alternative to dig.
I'm kind of wary of not shipping *basic* DNS tools which people expect to exist. drill is not a drop-in replacement for dig given that it ignores the +option flags. And no, I don't buy this "I disagree with upstream so I'm not shipping it" as an excuse to not only avoid BIND10, but drop BIND entirely.
On Wed, Mar 20, 2013 at 2:59 PM, Dave Reisner d@falconindy.com wrote:
glibc ships getent, which can be used to do DNS lookups (getent hosts www.google.com). That said, I don't expect people to know this offhand as an alternative to dig.
I'm kind of wary of not shipping *basic* DNS tools which people expect to exist. drill is not a drop-in replacement for dig given that it ignores the +option flags.
If there are tools that do the same job, albeit in a different way or with a different syntax, I don't see the big problem here...
And no, I don't buy this "I disagree with upstream so I'm not shipping it" as an excuse to not only avoid BIND10, but drop BIND entirely.
Would be simple enough to adopt the BIND package...
-t
[2013-03-20 09:59:47 -0400] Dave Reisner:
And no, I don't buy this "I disagree with upstream so I'm not shipping it" as an excuse to not only avoid BIND10, but drop BIND entirely.
This might not have been cristal clear: BIND has been crap for years. Not by my personal standards, but by objective measures such as the number of vulnerabilities found in it. Everybody involved with DNS software agrees that ldns+ unbound+nsd are superior alternatives.
Now BIND10 just turns the whole thing into a big joke.
Anyway, those packages are all yours now.
On wo, 2013-03-20 at 10:05 +0100, Thomas Bächler wrote:
Am 20.03.2013 04:50, schrieb Gaetan Bisson:
Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`.
Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands.
This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist.
As long as drill is not a drop-in replacement for dig, we shouldn't just replace it. Any DNS admin, even ones running Windows or PowerDNS, will use standard tools like "dig" to check domains. I've been implementing PowerDNS with DNSSEC last week, used dig +dnssec a lot to query for DNSSEC stuff. Drill doesn't support that, so it's a broken replacement in my eyes.
Just dropping the default choice of DNS resolving utilities because you don't like a new version of a server and its build system is complete crap. I don't like Apache 2.4 either, but instead of dropping Apache from the repos and replacing it with nginx I chose to keep 2.2.x and support that instead.
[2013-03-20 18:41:02 +0100] Jan de Groot:
Any DNS admin, even ones running Windows or PowerDNS, will use standard tools like "dig" to check domains. I've been implementing PowerDNS with DNSSEC last week, used dig +dnssec a lot to query for DNSSEC stuff. Drill doesn't support that, so it's a broken replacement in my eyes.
Of course it does support that: `drill -T -D` ...
Just dropping the default choice of DNS resolving utilities because you don't like a new version of a server and its build system is complete crap. I don't like Apache 2.4 either, but instead of dropping Apache from the repos and replacing it with nginx I chose to keep 2.2.x and support that instead.
Good for you. Now I package what I want on my spare time and, if there's a superior and easier-to-maintain alternative, I'm not going to waste any more of my time on a crumbling piece of software just because certain people cannot be bothered to migrate.
Over the past weeks we've transitioned all our packages depending on dnsutils to ldns, and now what's holding us back is that you guys are "used to" dnsutils!?! Frankly you disappoint me: I thought us devs had a good track record of putting technical merit before personal attachment to any piece of software.
By the way, you forgot to adopt dnsutils.
Gaetan Bisson schreef op 20.03.2013 22:35:
Good for you. Now I package what I want on my spare time and, if there's a superior and easier-to-maintain alternative, I'm not going to waste any more of my time on a crumbling piece of software just because certain people cannot be bothered to migrate.
Over the past weeks we've transitioned all our packages depending on dnsutils to ldns, and now what's holding us back is that you guys are "used to" dnsutils!?! Frankly you disappoint me: I thought us devs had a good track record of putting technical merit before personal attachment to any piece of software.
By the way, you forgot to adopt dnsutils.
FYI: I adopted dnsutils.
Maybe you should look into what you're talking about a big more. You started a complete dig/nslookup -> drill migration based on the fact that you don't like the build system used in bind10 and the fact that it's written in C++/Python.
I checked the bind10 source, it no longer includes dig and nslookup. The tests/system/README file specifies that it needs dig from BIND9 to run the testsuite...
I'm fine with ditching BIND, I always hated that nameserver, but BIND10 and dnsutils are completely different pieces of software.
Jan de Groot schreef op 22.03.2013 13:47:
FYI: I adopted dnsutils.
Maybe you should look into what you're talking about a big more. You started a complete dig/nslookup -> drill migration based on the fact that you don't like the build system used in bind10 and the fact that it's written in C++/Python.
I checked the bind10 source, it no longer includes dig and nslookup. The tests/system/README file specifies that it needs dig from BIND9 to run the testsuite...
I'm fine with ditching BIND, I always hated that nameserver, but BIND10 and dnsutils are completely different pieces of software.
To go down a bit further on this: https://bugs.archlinux.org/task/34404
Gajim is broken due to drill migration. Same for gnome-nettool, it uses the +options from dig, we missed that when doing the s/dig/drill/ patch on gnome-nettool.
IMHO we should just keep dnsutils and undo this migration. Replacing dig with drill all on our own without support from upstream projects or other distros makes life harder than you want.
On 22/03/13 22:47, Jan de Groot wrote:
Gaetan Bisson schreef op 20.03.2013 22:35:
Good for you. Now I package what I want on my spare time and, if there's a superior and easier-to-maintain alternative, I'm not going to waste any more of my time on a crumbling piece of software just because certain people cannot be bothered to migrate.
Over the past weeks we've transitioned all our packages depending on dnsutils to ldns, and now what's holding us back is that you guys are "used to" dnsutils!?! Frankly you disappoint me: I thought us devs had a good track record of putting technical merit before personal attachment to any piece of software.
By the way, you forgot to adopt dnsutils.
FYI: I adopted dnsutils.
Maybe you should look into what you're talking about a big more. You started a complete dig/nslookup -> drill migration based on the fact that you don't like the build system used in bind10 and the fact that it's written in C++/Python.
I checked the bind10 source, it no longer includes dig and nslookup. The tests/system/README file specifies that it needs dig from BIND9 to run the testsuite...
I'm fine with ditching BIND, I always hated that nameserver, but BIND10 and dnsutils are completely different pieces of software.
If no-one is taking bind, it should be dropped from the repos:
http://www.h-online.com/open/news/item/Critical-vulnerability-in-BIND-9-regu...
On Sat, Mar 9, 2013 at 3:27 AM, Gaetan Bisson bisson@archlinux.org wrote:
Currently we use the BIND code base in two packages:
- dnsutils from [core] provides basic DNS query tools;
- bind from [extra] is the actual name server.
With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost!
That mostly means two things:
- We cannot keep splitting dnsutils and bind anymore.
- I do not want to maintain these packages any further.
We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc.
So I suggest:
- Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases.
- We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community].
Comments or suggestions are welcome.
Bind is the worldwide most used DNS server[1], I think we should keep it in our repository. Note they also plan to merge ISC DHCP server into ISC BIND[2]. If nobody is interested I can take care of bind.
Cheers,
[1] http://en.wikipedia.org/wiki/BIND [2] http://www.isc.org/community/blog/201105/bind-10-dhcp
http://www.isc.org/community/blog/201105/bind-10-dhcp-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
arch-dev-public@lists.archlinux.org