Not sure for how back in time it holds, but the requirement against apr* in recen t subversion ebuild is not =dev-libs/apr-util-0*, but rather >dev-libs/apr-util-0.9.7 (or something similar depending on version). This leads to problems to people using ~* apache (2.2.4) which requires apr and apr-utils 1. Subversion builds right against those versions, but since the change marked in the Changelog as: 28 Jan 2007; Luca Longinotti <chtekk@gentoo.org> subversion-1.2.3-r2.ebuild, subversion-1.2.3-r3.ebuild, subversion-1.3.0.ebuild, subversion-1.3.1.ebuild, subversion-1.3.2.ebuild, subversion-1.3.2-r1.ebuild, subversion-1.3.2-r3.ebuild, subversion-1.4.0.ebuild, subversion-1.4.2.ebuild: Fix apr deps. emerge -puNDv worls tries to install a new slot apr-0* and apr-utils-0*, which are not needed at all. grep dev-libs/apr-util /usr/portage/dev-util/subversion/*.ebuild /usr/portage/dev-util/subversion/subversion-1.2.3-r2.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.2.3-r3.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.3.0.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.3.1.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.3.2.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.3.2-r1.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.3.2-r3.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.4.0.ebuild: =dev-libs/apr-util-0* /usr/portage/dev-util/subversion/subversion-1.4.2.ebuild: =dev-libs/apr-util-0* Quite probably all of those can stand the change from =dev-libs/apr-util-0* to >dev-libs/apr-util-0.9.7, as consulted with apache and subversion developers on irc (dlr notably, but also other). mod_dav_svn in subversion should be built with the same major apr-* version as apache itselt. Reproducible: Always
*** This bug has been marked as a duplicate of bug 159966 ***
It is not a duplicate: subversion was working with testing apache until an overrestrictive change in the ebuild (without a revision bump) forces me to a configuration that I know possitively will be broken: apache-2.2* with apr-1 and subversion-1.4* with apr-0 The ******ONLY****** restriction of subversion WRT slot is >apr-util-0.9.7, as versions below this one trigger specific bugs. It can perfectly be apr-1, and in fact I have been working with this combination since months ago. What is more: using apache-2.2.4 (~amd64) plus subversion-1.4.2 (~amd64) as the ebuilds are now guarantees that mod_dav_svn will dump core every time it is used. One can't mix different slots of apr in the same process.
I upgraded to subversion 1.4.3 today. I needed to edit the ebuild and digest, to change the apr dependency by >=dev-libs/apr-util-0.9.13 It works right, works well with apapche-2.2.4, etc. I still wonder what is the problem correcting the obvious mistake introduced 28 "Jan 2007; Luca Longinotti <chtekk@gentoo.org>" without other justification than "Fix apr deps" in the ebuilds, while it was actually screwing them for most cases. I insist that most 1.3 subversion versions **require** >0.9.7 (not just 0*), and that all recent ones can run with >0.9.7 or >0.9.13, not really sure. Google or the sources tell the story well.
I don't know what this all means, but subversion was a dependency for another ebuild and the following: [ebuild N ] dev-util/subversion-1.3.2-r3 USE="berkdb nls zlib -apache2 -bash-completion -emacs -java -nowebdav -perl -python -ruby" would not compile, giving this build error: cd subversion/tests/libsvn_subr && /bin/sh /var/tmp/portage/dev-util/subversion-1.3.2-r3/work/subversion-1.3.2/libtool --tag=CC --silent --mode=link i686-pc-linux-gnu-gcc -L/var/tmp/portage/dev-util/subversion-1.3.2-r3/image//usr/lib -O2 -pipe -march=pentium4 -fomit-frame-pointer -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pthread -D_LARGEFILE64_SOURCE -DNE_LFS -L/usr/lib -rpath /usr/lib -o target-test target-test.o ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib/libaprutil-0.la -lgdbm -ldb -lexpat /usr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread -ldl -lz /usr/lib/libaprutil-0.so: undefined reference to `db_create_4001' /usr/lib/libaprutil-0.so: undefined reference to `db_strerror_4001' collect2: ld returned 1 exit status make: *** [subversion/tests/libsvn_subr/target-test] Error 1 make: *** Waiting for unfinished jobs.... !!! ERROR: dev-util/subversion-1.3.2-r3 failed. When I upgraded apr from 0.9.6-r2 to 0.9.12, it then emerged cleanly.
as I commented, there were two errors around: - forcing slot 0 for every subversion ebuild - *not* forcing >=apr-util-0.9.7 for recent subversions You're hitting the second :)
Nope, nothing to do with subversion having only one slot. Not to do with actually forcing a recent apr (we don't have older ones) either. The problem is much more mundane. Just remerge apr-util and things will work again. It is caused by it being linked to an old db version without the apr-util library referring to db by itself. This should have been fixed some time ago, a new apr-util will fix that.
The dependencies are fixed in 1.4.3 @pauldv: you shouldn't be using ${ROOT} in --with-apr{,-util} in src_compile; and the ChangeLog entry refers to Bug 108777 which is completely unrelated to subversion or anything relevant.
The current version looks like this: apache_minor="(best_version apache | cut -d. -f2)" if [ ${apache_minor} -gt 0 ]; then apr_suffix="-1" fi [...] This results in apache_minor being empty and the test to fail, which is not good for apache-2.2.4 atleast.
apache_minor="$(best_version apache | cut -d. -f2)" or apache_minor=`best_version apache | cut -d. -f2` should both do the same thing in this case. Current version in cvs does not work.
I've fixed most of this. But Jakub, could you elaborate on the ${ROOT} thing?
(In reply to comment #10) > But Jakub, could you elaborate on the ${ROOT} thing? Yeah, you shouldn't use ${ROOT} in src_*; stuff always should be compiled against libs and headers in /; if you want to crosscompile or whatever, you need to configure your toolchain properly, not rely on ${ROOT} and break binpkgs on the way.
This bug is essentially fixed. Somebody substitute ${ROOT} with / in subversion-1.4.3-r1.ebuild, please.
The dependency has been fixed, I'll file a separate bug about the invalid ${ROOT} usage.
