When no jdk-1.4 is installed, =virtual/jdk-1.4* should select blackdown-jdk-1.4*. Calculating dependencies .... done! [ebuild NSf ] dev-java/sun-jdk-1.4.2.13 USE="X alsa nsplugin -doc -examples -jce" 0 kB [ebuild NS ] virtual/jdk-1.4.2 0 kB Similarly, =virtual/libstdc++-3.3 should select =sys-libs/libstdc++-v3-3.3*. Calculating dependencies .... done! [ebuild NS ] sys-devel/gcc-3.3.6-r1 USE="fortran gtk nls (-altivec) -bootstrap -boundschecking -build -doc -gcj (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -test -vanilla" 123 kB [ebuild N ] virtual/libstdc++-3.3 0 kB With portage 2.1.2, sun-jdk-1.4* and gcc-3.3* are selected. This is a bit annoying because sun-jdk-1.4 has fetch restrictions and gcc-3.3 isn't supported anymore. The following was the output of emerge --info yesterday when I noticed the problem. I have updated portage to 2.1.2_rc4-r9 since then. Portage 2.1.2_rc4-r8 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r3 i686) ================================================================= System uname: 2.6.19-gentoo-r3 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.12.8 Last Sync: Thu, 11 Jan 2007 14:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.19 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://ftp.club-internet.fr/pub/mirrors/gentoo http://trumpetti.atm.tut.fi/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ " LANG="en_GB.utf8" LC_ALL="en_GB.utf8" LINGUAS="en" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--quiet" 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" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa bash-completion berkdb bidi bitmap-fonts bonobo branding cairo cdparanoia cdr cjk cli cracklib crypt cscope cups dbus directfb dlloader dri dts dv dvd dvdr dvdread eds encode esd evo exif fam fbcon ffmpeg firefox flac fortran gd gdbm gif gnome gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml hal iconv idn ieee1394 imagemagick ipod ipv6 java joystick jpeg jpeg2k kerberos ldap libcaca libg++ libnotify mad mbox mikmod mime mmx mng mono mp3 mpeg nas ncurses nls nptl nptlonly nsplugin offensive ogg opengl oss pam pcmcia pcre pda pdf perl png ppds python qt3 qt4 quicktime readline recode reflection ruby samba sdl session spell spl sse sse2 ssl svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vcd vim-syntax vorbis win32codecs wmf x86 xine xml xorg xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard synaptics mouse" KERNEL="linux" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTDIR_OVERLAY I wonder if this could be related to the changes made for bug #159360. I can't remember seeing this behaviour before.
This is the intended behavior. Sorry, you'll just have to accept it.
This is intended even when the installed version of y is in a different slot? If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so is there some alternative that can be used in the ebuild?
(In reply to comment #2) > This is intended even when the installed version of y is in a different slot? Yes, the preference effect crosses slot boundaries since the presence of a given package (regardless of slot) is a general indication that the package is preferred over other possible choices. Of course there may be some cases where this preference algorithm chooses something different that what the user would truly prefer. In that case, the user can manually install the desired package or to mask the unwanted package. > If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so > is there some alternative that can be used in the ebuild? The only alternative at the ebuild level is to remove gcc as a choice.
(In reply to comment #3) > (In reply to comment #2) > > If so, the libstdc++ example really should prefer libstdc++-v3 over gcc-3.3, so > > is there some alternative that can be used in the ebuild? > > The only alternative at the ebuild level is to remove gcc as a choice. > echo "virtual/libstdc++ minimal" >> ${PORTDIR}/profiles/base/package.use RDEPEND="|| ( =sys-libs/libstdc++-v3-3.3* !minimal? ( =sys-devel/gcc-3.3* ) )"
(In reply to comment #4) > echo "virtual/libstdc++ minimal" >> ${PORTDIR}/profiles/base/package.use > RDEPEND="|| ( =sys-libs/libstdc++-v3-3.3* !minimal? ( =sys-devel/gcc-3.3* ) )" I think that's kind of an ugly way to do it. If it's really necessary to prevent gcc-3.3* from being pulled in, I think a better solution would be to mask gcc-3.3* in the relevant profiles (since most people won't be using gcc-3.3* anymore anyway).
I've just noticed that GLEP 37 mentions a package.prefer that has never been implemented: http://www.gentoo.org/proj/en/glep/glep-0037.html#overrides Something like that should be helpful for situations like this bug.
Hi! I believe this strange thing happend to you (as well as with me), because you are using a profile not the one you are used to! (the x86/no-ntpl requires gcc-3.3.6-r3 with libstdc++ BUT the simple 2006 profile does not.) Cheers! Semir
Some more things: if ACCEPT_KEYWORDS=~x86 is set in /etc/make.conf, it will still emerge gcc-3.3.6. Do: 1. remove ACCEPT_KEYWORDS=~x86 from make.conf 2. (correct symlinks of /etc/make.profile. Actually now I dont really know if it has anything to do with this bug :]) 3. echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords Before: emerge -u --newuse --deep -p world | grep gcc [ebuild U ] sys-devel/gcc-config-1.3.15 [1.3.13-r3] [ebuild NS ] sys-devel/gcc-3.3.6-r1 USE="gtk nls test (-altivec) -bootstrap -boundschecking -build -doc -fortran -gcj (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -vanilla" After: emerge -u --newuse --deep -p world | grep gcc [ebuild U ] sys-kernel/linux-headers-2.6.17-r2 [2.6.11-r2] USE="-gcc64%" [ebuild U ] sys-devel/gcc-config-1.3.14 [1.3.13-r3] [ebuild N ] x11-misc/gccmakedep-1.0.2 USE="-debug Quite like some shampoo, isnt it? :D Hope, now I really solved it!
> Some more things: if ACCEPT_KEYWORDS=~x86 is set in /etc/make.conf, it will > still emerge gcc-3.3.6. > Do: 1. remove ACCEPT_KEYWORDS=~x86 from make.conf > 2. (correct symlinks of /etc/make.profile. Actually now I dont really > know if it has anything to do with this bug :]) > 3. echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords None of the above worked for me. I just put <=sys-devel/gcc-3.3.4-r1 in /etc/portage/package.mask. Appears to be fine.
*** Bug 174201 has been marked as a duplicate of this bug. ***
*** Bug 177099 has been marked as a duplicate of this bug. ***
*** Bug 178752 has been marked as a duplicate of this bug. ***
*** Bug 213936 has been marked as a duplicate of this bug. ***
*** Bug 239390 has been marked as a duplicate of this bug. ***
*** Bug 255790 has been marked as a duplicate of this bug. ***
