BIND rpm's for rh9?

Gushi google at
Wed Nov 8 20:49:50 UTC 2006

Chris Cox wrote:
> Gushi wrote:
> > Hey all,
> >
> > I'm interested in running the latest BIND so I can try doing all those
> > neat DNSSEC things, but I'm using an old redhat 9 machine, with a VERY
> > custom kernel and some VERY odd hardware.
> >
> > Does anyone know of a generic location to get rpms which will work (or
> > failing that, srpms which I can compile myself).  I'm mainly interested
> > in maintaining my dependencies and such, as opposed to just building
> > bind from scratch (which I've got right now, but it's a few versions
> > old, and it bothers me for some reason, since none of the file paths
> > match where redhat seems to think they should be).
> >
> Your statements are contradictory.  You say you want maintenance and
> dependency checking, but you're running a very CUSTOM RH9.  RH9 since
> it is NOT support and hasn't been for a VERY long time, you are
> forced to do your own package mgmt.  That's just the way it goes.

Note: I'm answering this via google groups because my bind-list mail
was purged.

I am using a standard redhat 9 on a cobalt raq which uses a custom 2.4
kernel, and like some other older processors, I cannot use i686
architecture stuff.  I have my own kernel RPMs for this distro, and
they work.  Everything else IS standard.  My only other option is

I've been told numerous times in the past that building from source is
BAD because it breaks rpm-bound dependencies and if you build something
from source, and then later install the RPM to SATISFY some other
dependency, you stomp your custom compile.

Having two sets of binaries is worse, because then the system defaults
(installed via rpm in places like /usr/bin) will take precedence as
they are first in the default path.

Placing your binaries elsewhere breaks what I consider to be "expected
behavior".  I expect zonefiles to be in /etc/namedb (or someplace that
is symlinked to there).  I expect correct versions of dig, nslookup,
and friends to be in my path by default.  Every BSD system I use has
named in /usr/sbin (and all the packaging, ports and other systems)
know not to stomp it, or know to upgrade it accordingly.

I want ONLY ONE copy of the relevant files around to both avoid
confusion and make backups and maintenance easy.   I would also like to
still get the benefits of the rpm (proper system startup scripts which
comply with the RH standards, proper syslog entries, etc).

I spent three hours explaining this to #fedora, amidst (conflicting)
answers of "just build from source", or people trying to explain things
about questions I had already answered, or telling me to upgrade this
server (a production machine) to fedora core 1 (which accomplishes
nothing, as it's JUST as unsupported, and has no newer a bind).

Building from source doesn't accomplish this.  No standardly available
RPM accomplishes this.  Building from an SRPM yields such inane
dependencies as dbus-devel, openldap-devel, postgresql-devel (none of
which I need to build from source, so why would I need them
otherwise?), and the srpm as well seems to attempt to add a number of
nonstandard patches I've never needed before:


In short, my answer is probably going to be to rape the hell out of an
srpm, strip out all the stupid dependencies and packages, and build a
"noarch/nodist" rpm that installs standalone in the same locations as
any other RPM, but which satisfies any other version requirements of
anything else I may need.

I was asking if anyone else had been through this, and if they knew a
way of handling it, as going through rigorous OS upgrades doesn't seem
a practical point.  I apologize for seeming off-topic here.  My
original question was quite bind-relevant (i.e. where can I find bind
precompiled for X), and on both mailing lists and IRC I've gotten
requests for more information, and the explanation that I'm "doing it

Trust me, if I could on this hardware, I'd be running FreeBSD.

15:32:13  up 366 days, 15:48,  1 user,  load average: 0.09, 0.16, 0.17

> BIND is a straight forward build...
> Paths can be adjusted.

More information about the bind-users mailing list