Bugzilla Bug 114481

http://dev.gentoo.org/~betelgeuse/scripts/checkdeps
Use that to checkdeps:
pena commons-graph # emerge -pv subversion

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] dev-util/subversion-1.3.0_rc4  -apache2 +bash-completion -berkdb
-emacs -java -nls -nowebdav -perl -python -ruby +zlib 0 kB

betelgeuse@pena ~/bin $ checkdeps subversion
dev-libs/apr
dev-libs/apr-util
dev-libs/expat
dev-libs/openssl
dev-util/subversion
net-misc/neon
sys-libs/db
sys-libs/gdbm
sys-libs/glibc
sys-libs/zlib

From the list I can see for example the following issues:
1. expat is not listed as a dependency
2. subversion is linked against db althought the berkdb use flag is off
3. openssl dep is missing

You can use the tool to do further investigation yourself.

Well, expat is a dependency of neon, not subversion. berkdb is pulled in
optionally by apr/apr-util, and ssl is also an optional neon dependency.

Btw. you forgot about gdbm (from apr/apu). Also the berkdb useflag will disable
building the berkeley db based backend. It will not stop the subversion stuff
being indirectly linked against it.

(In reply to comment #2)
> Btw. you forgot about gdbm (from apr/apu). Also the berkdb useflag will disable
> building the berkeley db based backend. It will not stop the subversion stuff
> being indirectly linked against it.

The script checks for direct linking. Well let's just wait for verify-rdepend
that will come in 2.0.54 then. It should be doing about the same thing as my
script but we shall see.

        berkdb? ( =sys-libs/db-4* )

My point is that with this kind of dependency you imply that subversion will not
link against db with the berkdb use flag off.

Welcome to libtool mayhem. Subversion will really only use those libraries
based
on the dependencies. ssl is used when neon uses ssl, and not when neon does not
use ssl. The same for the database libs.

subversion will still try to link to berkdb, and fail to compile, if berkdb is
not installed and the berkdb USE flag disabled.


/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -ldb-4.2

What is the output of "apu-config --libs" If -ldb is in there you first need to
rebuild apr-util.

(In reply to comment #6)
> What is the output of "apu-config --libs" If -ldb is in there you first need to
> rebuild apr-util.

-ldb is not there.

Problem seems to be an issue with subversion-db4.patch, which didn't occur with
subversion 1.2.3 (I only tried with 1.2.3 and 1.2.3-r2, not with -r1 or
1.3.0_rc4).

Modifying the ebuild to only apply the patch if the berkdb use flag is set
seems to fix the problem.

Mathew, that check only changes the db library names the configure script looks
for. The point is that it shouldn't look at all. In any case it seems to me
that apr-util is broken. It does not respect the -berkdb flag, and just links
against db when found. 

Apr-util is built against db if "ldd -r /usr/lib/apr-util-0.so|grep db_create"
returns results. Subversion will link against db when it is needed for
apr-util, so more than likely always. I'll look what hapens with a fixed
apr-util.

Now my script uses scanelf so I get direct deps out of it:
betelgeuse@pena ~/overlays/betelgeuse/net-wireless/ndiswrapper $ checkdeps.rb
subversion
dev-libs/apr
dev-libs/apr-util
dev-libs/expat
dev-libs/openssl
dev-util/subversion
net-misc/neon
sys-libs/db || app-office/openoffice-bin
sys-libs/gdbm
sys-libs/glibc
sys-libs/zlib

http://dev.gentoo.org/~betelgeuse/scripts/checkdeps.rb

I've just checked with a fixed apr-util (note that apr-util will not properly
link against the db library (or any other libs for that matter), but does need
symbols from it. As such checking whether it needs the db_create_4002 symbol
checks whether it requires db. I just created a fixed apr-util for myself that
doesn't link against berkeley. In that case subversion doesn't link against it
either.

Petteri: Your script does what it's supposed to do. It checks the libraries
that a package builds against. It does not however know which ones come from
dependencies. My subversion for example is also linked against openldap by way
of apr-util. The apr-util library however does not export its dependencies. It
only specifies them in the apr-util script.

ps. The ldd -r check should be "ldd -r /usr/lib/libaprutil-0.so 2>&1 |grep
db_create". I forgot the redirect

(In reply to comment #12)
> 
> Petteri: Your script does what it's supposed to do. It checks the libraries
> that a package builds against. It does not however know which ones come from
> dependencies. My subversion for example is also linked against openldap by way
> of apr-util. The apr-util library however does not export its dependencies. It
> only specifies them in the apr-util script.
> 

The problem that the new version fixes is that using ldd lists also
dependencies of dependencies.

Which leaves the problem that libaprutil-0.so does not properly link against
the libraries it uses. Leaving it to users of the library to do so. And
apr-util is not the only library to do so. I think this is broken behaviour,
but hardly subversions fault. But as such one still cannot say that the new
script shows understanding of the packages. Trust me, the subversion sourcecode
in no place uses openldap. Still it links against it just because apu-config
--libs tells it to.

Could you check the berkdb dependency again, with a rebuild apr-util without
berkdb deps.

(In reply to comment #15)
> Could you check the berkdb dependency again, with a rebuild apr-util without
> berkdb deps.
> 

Maybe you can use the as-needed feature of ld to fix this stuff on the
subversion side?

I can't apr-util is "broken", subversion isn't. In any case subversion does not
need to directly depend as it's dependencies already do.

*** Bug 118569 has been marked as a duplicate of this bug. ***

*** Bug 130281 has been marked as a duplicate of this bug. ***

*** Bug 132660 has been marked as a duplicate of this bug. ***

*** Bug 53650 has been marked as a duplicate of this bug. ***

*** Bug 153322 has been marked as a duplicate of this bug. ***

*** Bug 154312 has been marked as a duplicate of this bug. ***

*** Bug 186827 has been marked as a duplicate of this bug. ***

*** Bug 190293 has been marked as a duplicate of this bug. ***

*** Bug 191409 has been marked as a duplicate of this bug. ***

*** Bug 191722 has been marked as a duplicate of this bug. ***

*** Bug 191812 has been marked as a duplicate of this bug. ***

*** Bug 191824 has been marked as a duplicate of this bug. ***

*** Bug 192419 has been marked as a duplicate of this bug. ***

*** Bug 196355 has been marked as a duplicate of this bug. ***

Subversion >=1.5_pre ebuilds use my patch which fixes this bug.