I am trying to emerge www-servers/tomcat with ACCEPT_KEYWORDS=~x86. This emerge pulls in lots of packages. For me the emerge came to an early halt because dev-java/commons-digester-1.7 requires (a particular version of?) dev-java/commons-beanutils which is not automatically included on the list of packages to be emerged. Manually emerging commons-beanutils-1.6.1-r2 seems to fix the problem. I have gone through the steps of the java upgrade guide, and I am currently trying to run Java 1.4 only. My emerge --info is: Gentoo Base System version 1.6.14 Portage 2.1.1_pre2-r2 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.14-gentoo-r5 i686) ================================================================= System uname: 2.6.14-gentoo-r5 i686 Pentium III (Coppermine) dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-pipe -O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-pipe -O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apache2 arts avi berkdb bitmap-fonts cli crypt cups dlloader doc dri eds emacs emboss encode esd examples foomaticdb fortran gd gdbm ggi gif glut gnome gpm gstreamer gtk gtk2 imlib ipv6 isdnlog java jpeg kde libg++ libwww mad mikmod mmx motif mp3 mpeg ncurses nls nptl ogg opengl oss pam pcre pdf pdflib perl plotutils png pppd python qt qt3 qt4 quicktime readline real reflection sdl session source spell spl ssl svga tcltk tcpd truetype truetype-fonts type1-fonts udev vorbis win32codecs xml xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
From commons-digester-1.7.ebuild: RDEPEND=">=virtual/jre-1.4 =dev-java/commons-beanutils-1.6* >=dev-java/commons-collections-2.1 >=dev-java/commons-logging-1.0.2" DEPEND=">=virtual/jdk-1.4 >=dev-java/ant-core-1.4 junit? ( >=dev-java/junit-3.7 ) jikes? ( dev-java/jikes ) source? ( app-arch/zip ) ${RDEPEND}" It has dev-java/commons-beanutils in {R,}DEPEND.
dev-java/commons-beanutils is on the RDEPEND list of the commons-digester-1.7.ebuild. But shouldn't it be on the DEPEND list instead, since it is apparently needed already at emerge time? The same reasoning goes for this bug: http://bugs.gentoo.org/show_bug.cgi?id=139137
Please note that DEPEND has in last line ${RDEPEND}, so it contains all atoms from RDEPEND.
> Please note that DEPEND has in last line ${RDEPEND}, > so it contains all atoms from RDEPEND. I didn't realize that, thank for pointing it out. But why is it then that commons-beanutils is not emerged automatically? Can we really consider this problem resolved?
Make sure you have the most recent revision of =dev-java/commons-beanutils-1.6* . IIRC correctly, it was slot 0 at some point, and moved to slot 1.6. This required a revision bump. Basically, that atom is trying to get around lack of a SLOT based dependency. So, if you had a revision of 1.6 that was slot 0, it would fill the dependency, but java-pkg_jar-from wouldn't be able to find it at the right slot.
