Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 61933 - Subversion 1.0.6 should depend on berkdb
Summary: Subversion 1.0.6 should depend on berkdb
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Paul de Vrieze (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-27 08:22 UTC by theboywho
Modified: 2004-08-27 13:35 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description theboywho 2004-08-27 08:22:04 UTC
Emerging subversion 1.0.6 fails on this:

checking for socket in -lsocket... no
checking for availability of Berkeley DB... no
configure: error: Berkeley DB 4.0.14 wasn't found.

!!! ERROR: dev-util/subversion-1.0.6 failed.
!!! Function econf, Line 362, Exitcode 1
!!! econf failed

The result should be a sucsessful ebuild.
Comment 1 theboywho 2004-08-27 08:25:29 UTC
Just noticed that it does...the build says:

# Note that to disable the server part of subversion you need to specify
# USE="-berkdb" emerge subversion.

i have -berkdb in my use flags - so surely the subversion libraries should emerge:

My emerge info:

Portage 2.0.50-r10 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r2)
=================================================================
System uname: 2.6.8-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz
Gentoo Base System version 1.5.3
distcc 2.16 i386-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer"
CHOST="i386-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/NX/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache debug distcc nostrip sandbox"
GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acl acpi alsa apache2 arts berkdb bluetooth crypt cups curl debug expat fbcon flash foomaticdb gd gdbm gif imap imlib innodb javascript jpeg kde lcms ldap libg++ libwww mad maildir mcal mikmod mmx moznocompose moznoirc moznomail mozsvg mssql mysql ncurses nls nogcj oav oci8 odbc oggvorbis opengl oss pam pdflib perl php png ppds python qt readlinesamba slang spell sqlite sse sse2 ssl svga tcpd tiff truetype usb wmf x86 xinerama xml xml2 xv zlib"
Comment 2 David 2004-08-27 08:56:44 UTC
By the look of your Portage info, you have "berkdb" not "-berkdb" in your USE flags.

You have a number of choices if you are not merging with: # USE="-berkdb" emerge subversion

1) Disable the berkdb flag globally, by editing /etc/make.conf
2) Disable it temporarily for the duration of the build, by merging using the command above (this doesn't work so well for when you upgrade, however)
3) Disable it for the one package, by putting "dev-util/subversion -berkdb" (without quotes) into /etc/portage/package.use (create if necessary).
Comment 3 Paul de Vrieze (RETIRED) gentoo-dev 2004-08-27 13:35:27 UTC
Strange, if berkdb is not in the useflags, the configure script should find it is not there and not build the berkeley db backend and the servers. For my machine it works that way allthough it actually does have a working berkeley db installed. It has a dependency on berkdb if it exists in the useflags. Failing in that case is the correct behaviour. Trying to work around the ebuild with --nodeps is counterproductive in this case. Also take a look at david's tips