Comment 7 for bug 689896

Regarding

> So if we want use db48 and not 51 we just specify a right path
> -I/usr/include/db48.

Yep. That is usually what I try to achieve. However, that also forces
RPM to lag choosing what Berkeley DB version to choose, dependent
on what distros choose to pick up. The delay is adoption is measured in
months and years, and db-5.1.19 -- while it _HAS_ been picked up surprisingly
fast -- is not gonna be any exception.

But if you are truly interesetd (in Arch linux) in supporting mutiple versions
of Berkeley DB, the convention of installing into /usr/include/db51 is
hardly surprising.

The harder issue for a distro is
   What version goes into /usr/include/db.h?
which is pretty easily handled by alternative symlinks into /usr/include/dbXY,
independently of whether RPM itself chooses to do (as in rpm-5.3.6)
   #include <db51/db.h>
or (I prefer -I/usr/include/db51 in CFLAGS personally)
    CFLAGS="... -I/usr/include/db51 ..."
    #include <db.h>

The harder issue atm is that RPM is trying to support "embedded sqlite" using
the dual access in db-5.x and (atm) there's a limitation in RPM_CHECK_LIB()
that forces <db51/db.h> not <db.h> for AutoFu. This can/will be fixed as rapidly
as can be managed (because I prefer the flexibility of -I/usr/include/db51).

Meanwhile, what's in rpm-5.3.6 was quite consciously/deliberately chosen
and the issues are well known: aggresively/narrowly targeting db-5.1.19
and dual SQL <-> CRUD access has implementation costs.