Debian: apu-config and BDB

[Ben Reser <be...@reser.org>]

Since the change that was made in reaction to this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622081

apu-config on Debian has avoided returning the BDB library from
--libs.  The bug suggests that BDB is related to the DBM support in
APR Util.  This is actually not the case.  They are two separate
database interfaces supported by APR Util as can be seen by the two
separate API pages for them:
http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___d_b_d.html
vs
http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___d_b_m.html

The bug also says that it thinks this dependency is useless. It may be
useless for some projects that aren't using the bdb features of the
library. Those that are using the bdb features will have problems with
their build system as a result of this change.

For example.  Subversion would not detect BDB on Debian based systems
due to this change (until I made a change to our build system to work
around this).

Ultimately there are two failures here.

1) You shouldn't be changing apu-config's output in order to remove
dependencies that are useless for a particular project.  Rather you
should patch that's project's use of apu-config to filter those things
out.

2) Passing --dbm-libs to get BDB libraries is wrong.

I'd strongly advise that this change be reverted and that the packages
that end up with BDB dependencies that are undesirable be fixed.
Alternatively, you could add --avoid-bdb and --bdb-libs flags to
apu-config.  I'd suspect that something like that would be accepted
upstream by APR-UTIL.

I'd urge the Debian project not to unilaterally take it upon itself to
change the default behavior of a configuration tool like this.

Re: Debian: apu-config and BDB

[Ben Reser <be...@reser.org>]

On Fri, Nov 23, 2012 at 6:35 AM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> You are confusing two things here. Apr-util dbm is an abstraction for
> key-value-type database libraries of which BDB is one possible
> provider.
>
> Apr-util dbd (note the different order of the letters than bdb) is an
> abstraction for sql database engines (e.g. mysql, postgresql, ...).

You're right my mistake.

> Apr-util provides a full abstraction for the dbm backends. There is no
> need and no way for a consumer of the apr-util dbm API to directly
> call functions of the backend library and make them interact with apr-
> util's dbm functions. Therefore, on Linux it is unnecessary for any
> consumer of the apr-util dbm API to directly link to the dbm libraries
> (except for linking statically). It is enough that apr-util links to
> the dbm libraries (like DBD). Therefore it is generally a good idea on
> Linux to not output the dbm libraries by default. So, it's more a
> platform specific thing than something related to a specific project.

Alright I see your point.  I still think it would have been better to
modify individual packages to pass --avoid-dbm.

> Subversion is (or was?) using apr-util's detection code of BDB without
> using apr-util's dbm API. This is an abuse of apu-config. There is no
> reason at all why subversion would need to use the same version of BDB
> as apr-util does. In fact, this interdependency had caused problems in
> Debian in the past.

It's an abuse of apu-config that's true.

My understanding (as well as other SVN devs understanding) was that we
did this because we were concerned about potentially getting a
different version of BDB by way of APR-UTIL than what we were linked
against when we're run inside httpd.  Our error messages seem to imply
this...

However, digging back in the history it does not seem that this was
done this way for that reason at all:
http://subversion.tigris.org/issues/show_bug.cgi?id=957

I'm not finding any history of a problem coming up from this httpd
mismatch.  However, that doesn't mean it didn't happen or can't
happen.  So I'm somewhat disinclined to unwind this without doing a
lot of work to prove that it can't cause a problem.

Given that most people use fsfs instead of the bdb based file system
I'm left with a whole lot less anecdotal evidence of what the reality
here is.

> We will make changes to make packages work together flawlessly. I
> don't think this particular change is a very intrusive one. But if the
> current subversion still has a problem with it, it may be a good idea
> to make it pass --dbm-libs by default.

That's what I've done (though it's a tad more complicated because
older versions of apu-config don't support --dbm-libs).

Re: Debian: apu-config and BDB

[Stefan Fritsch <sf...@sfritsch.de>]

On Thursday 22 November 2012, Ben Reser wrote:
> Since the change that was made in reaction to this bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622081
> 
> apu-config on Debian has avoided returning the BDB library from
> --libs.  The bug suggests that BDB is related to the DBM support in
> APR Util.  This is actually not the case.  They are two separate
> database interfaces supported by APR Util as can be seen by the two
> separate API pages for them:
> http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___d_b_
> d.html vs
> http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___d_b_
> m.html
> 

You are confusing two things here. Apr-util dbm is an abstraction for 
key-value-type database libraries of which BDB is one possible 
provider.

Apr-util dbd (note the different order of the letters than bdb) is an 
abstraction for sql database engines (e.g. mysql, postgresql, ...).

> The bug also says that it thinks this dependency is useless. It may
> be useless for some projects that aren't using the bdb features of
> the library. Those that are using the bdb features will have
> problems with their build system as a result of this change.
> 
> For example.  Subversion would not detect BDB on Debian based
> systems due to this change (until I made a change to our build
> system to work around this).

Apr-util provides a full abstraction for the dbm backends. There is no 
need and no way for a consumer of the apr-util dbm API to directly 
call functions of the backend library and make them interact with apr-
util's dbm functions. Therefore, on Linux it is unnecessary for any 
consumer of the apr-util dbm API to directly link to the dbm libraries 
(except for linking statically). It is enough that apr-util links to 
the dbm libraries (like DBD). Therefore it is generally a good idea on 
Linux to not output the dbm libraries by default. So, it's more a 
platform specific thing than something related to a specific project.

Subversion is (or was?) using apr-util's detection code of BDB without 
using apr-util's dbm API. This is an abuse of apu-config. There is no 
reason at all why subversion would need to use the same version of BDB 
as apr-util does. In fact, this interdependency had caused problems in 
Debian in the past.

> Ultimately there are two failures here.
> 
> 1) You shouldn't be changing apu-config's output in order to remove
> dependencies that are useless for a particular project.  Rather you
> should patch that's project's use of apu-config to filter those
> things out.
> 
> 2) Passing --dbm-libs to get BDB libraries is wrong.
> 
> I'd strongly advise that this change be reverted and that the
> packages that end up with BDB dependencies that are undesirable be
> fixed. Alternatively, you could add --avoid-bdb and --bdb-libs
> flags to apu-config.  I'd suspect that something like that would
> be accepted upstream by APR-UTIL.

No, it is not. BDB is one dbm provider.

> I'd urge the Debian project not to unilaterally take it upon itself
> to change the default behavior of a configuration tool like this.

We will make changes to make packages work together flawlessly. I 
don't think this particular change is a very intrusive one. But if the 
current subversion still has a problem with it, it may be a good idea 
to make it pass --dbm-libs by default.