I have both stable eclipse-sdk and ibm-jdk-bin emerged, but now I can't do an emerge -up --deep world It shows a dependency problem saying all ebuilds that could satisfy ">=virtual/jdk-1.3" have been masked even though I jave dev-java/ibm-jdk-bin-1.4.1-r2 installed. I even tried injecting dev-java/ibm-jdk-bin-1.4.2. Reproducible: Always Steps to Reproduce: 1. Emerge dev-java/ibm-jdk-bin 2. Emerge dev-util/eclipse-sdk with an ebuild prior to current stable X86 ebuild 3. try to "emerge -up --deep world" Actual Results: These are the packages that I would merge, in order: Calculating world dependencies / !!! all ebuilds that could satisfy ">=virtual/jdk-1.3" have been masked. !!! possible candidates are: - dev-java/ibm-jdk-bin-1.4.2 (masked by: ~keyword) - dev-java/ibm-jdk-bin-1.4.1-r2 (masked by: ~keyword) !!! (dependency required by "dev-util/eclipse-sdk-2.1.3-r3" [ebuild]) !!! Problem with ebuild dev-util/eclipse-sdk-2.1.3-r3 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Expected Results: Let me update my system. I haven't been able to update for a couple days now! Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8.1-mm4) ================================================================= System uname: 2.6.8.1-mm4 i686 AMD Athlon(tm) Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -ftracer -fomit-frame-pointer -momit-leaf-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -ftracer -fomit-frame-pointer -momit-leaf-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://sunsite.ualberta.ca/pub/unix/Linux/gentoo http://www.ibiblio.org/pub/Linux/distributions/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://cs.ubishops.ca/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dfx 3dnow X aalib alsa apache2 apm arts avi berkdb bitmap-fonts crypt cups dga directfb divx4linux dvd encode foomaticdb gdbm gif gpm gtk gtk2 guile imap imlib java jikes jpeg kde leim libcaca libg++ libwww live mad maildir mikmod mmx motif mpeg nas ncurses nls objc oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang smooth spell sse ssl svga tcltk tcpd tetex theora tiff truetype usb video_cards_3dfx voodoo3 wmf x86 xml xml2 xmms xprint xv xvid zlib"
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap4
I understand why it normally happens, I don't think this is a bug with the ebuild persay, but is this a bug with portage? "!!! all ebuilds that could satisfy ">=virtual/jdk-1.3" have been masked." is obviously wrong, there are multiple choices for JDKs >= 1.3 I even have dev-java/sun-jdk-1.4.2.05 installed. > qpkg -nc -I | grep jdk dev-java/ibm-jdk-bin dev-java/sun-jdk > emerge -p sun-jdk These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild RF ] dev-java/sun-jdk-1.4.2.05
Sorry to reopen this bug but I don't think Andrew Ross fully read/understood the report. Portage is incorrectly telling me there is nothing that satisfys ">=virtual/jdk-1.3", when I know this not to be the case. On a hunch I installed the latest portage (2.0.51_rc4) and things now work as expected! This is good news for me but I've talked with others who have had the same odd dependency problems but just gave up and unmerged the packages in question to get things working again. People should be able to use gentoo without any ~x86 packages (especially a ~x86 portage). Can a newer version of portage be moved to stable x86?
There are still few small yet valid problems pop up with portage 2.0.51 - few changes every day is not "stable x86" material. Once portage 2.0.51 will be deemed stable this problem will go away...
Understandable. I had seen so many portage updates before in the past I didn't realize this one was a big leap. I hear there's no way to go back to the 2.0.50 if there's a problem... I hadn't been told that before upgrading to the 2.0.51 version of portage, it's not a problem for me (yet), but that does make bumping it a more serious issue. Does this small problem have an equally small fix that can be backported to 2.0.50 series, or is this just something to tell people to work around until the 2.0.51 of portage is stable?
it works with .51 because it calculated virtual on the spot it probably can't resolf the virtual on .50 because your virtuals file is broken (notting the jave team can do about that)
