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.
