Summary: | dev-util/subversion depends on =dev-libs/apr-util-0* | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Santiago Gala <sgala> |
Component: | New packages | Assignee: | Paul de Vrieze (RETIRED) <pauldv> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | albert+gentoo-bugzilla, apache-bugs, basdebakker, jakub |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 169289 |
Description
Santiago Gala
2007-02-18 19:55:45 UTC
*** 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. |