Bugzilla Bug 161953

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 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. ***