Comment 4 for bug 689896

On Wed, Dec 15, 2010 at 3:31 PM, Jeff Johnson <email address hidden> wrote:
> What is "uncleanly" about the solution
>        ln -s . /usr/include/db51
> which I suspect is enough to get your build working.
Unfortunately no, this fail later. I'm investigating.

Uncleanly, because, we should be able to choose which version of db we
want to use by ./configure or -I/usr/include/dbxx/
So if we want use db48 and not 51 we just specify a right path
-I/usr/include/db48.

After that, package is build as non-root and he cannot add
/usr/lib/db51/db.h before it start building, so we have to modify a
clean package of berkeley db to add a symlink to the current version
of db. I'll have to deal to db maintener.

> Many linux (and unix) systems have multiple Berkeley DB versions installed,
> and /usr/include/db.h isn't sufficiently reliable/portable.
Yes my debian have 3 versions, but they are still _one_ version of
/usr/include/db.h. lib48-dev packages are mutualy exclusive.

> Note that RPM also needs to work on non-linux, where /usr/include (and Berkeley DB)
> are all installed differently to what Debian does.
Yes of course! That's my problem, it don't build on one unix ;)
But as i said, finding the path of headers should be configurable, not
static in $INCLUDE/db51/db.h.

> This is in fact why Berkeley DB used to be bundled with RPM ...
>
> If you wish to pursue this approach I will identify and document all the steps
> needed (its not hard).
Stop bundling librairy with the binary is great and I don't want to
stop you in your swing. Find a way to correctly give the path of db.h
is a better way. No?

>> 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.
bdb is annoying to manage...

>
> 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")
We don't speak about bdb version but bdb PATH. This is just a question of path.

It's not a stupid to considere just using #include <db.h> and not
#include <db51/db.h> which my test patch do.
After that, it's free to compile with -I/usr/include/db51 to compile
or choose and default version and make a symlinks.
This seems (to me) the better way.

Another small point:

This line let think that berkeley-db is optional in building of rpm
Berkeley-DB [1] optional 5.1.19 5.1.19
http://www.oracle.com/database/berkeley-db.html

but when i try to build whitout it : i cannot. Normal?

--
Sébastien Luttringer
www.seblu.net