Comment 3 for bug 689896

What is "uncleanly" about the solution
 ln -s . /usr/include/db51
which I suspect is enough to get your build working.

Many linux (and unix) systems have multiple Berkeley DB versions installed,
and /usr/include/db.h isn't sufficiently reliable/portable.

Note that RPM also needs to work on non-linux, where /usr/include (and Berkeley DB)
are all installed differently to what Debian does.

This is in fact why Berkeley DB used to be bundled with RPM: for
painless reliable "no-brainer" installation. Sadly, that does
not please anyone who wishes to use "system" Berkeley DB,
a concept that is mostly meaningless when there are multiple
versions of Berkeley DB installed on the "system".

You can still build with Berkeley DB internal if you untar db-5.1.19.tar.gz
into rpm's top level directory, rename
 mv db-5.1.19 db
and then add
 --with-db=internal
 --with-dbsql=internal
You might also need
 ln -s db db51
to be able to build.

If you wish to pursue this approach I will identify and document all the steps
needed (its not hard).

> This is also why autotools don't detect that berkeley db is missing,
> because he detect it. I think you should fix that in the code.

I don't disagree, but there's no pleasing everyone, or handling
all possible ways to install Berkeley DB, including version tests
and internal <-> external, automagically using autoconf tests.

Nor is there any RPM development reason to chase every possible
Berkeley DB version everywhere. Instead, one single version is
being targeted (older versions back to db-4.5.x will work) and
with one recommended installation of Berkeley DB
(relevant to your case, /usr/include/db51/db.h is "recommended")