When trying to do an "emerge -e system" with the "doc" use flag set, portage thinks it needs sun-jdk, when it should only need blackdown-jdk. I found that if I altered the sys-libs/db-4.1.25_p1-r3 ebuild to specify dependences on dev-java/blackdown-{jdk,jre} instead of virtual/{jdk/jre} explicitly, then only blackdown was included. To me, it looks like either there's a bug in the db-4.1.25_pl-r3 ebuild, or more probably it's something obscure with portage. It's worth noting that I currently have both blackdown and sun jdks installed; it doesn't make any difference which jdk is currently selected. ---- snippet from sys-libs/db-4.1.25_p1-r3 ebuild DEPEND="tcltk? ( dev-lang/tcl ) java? ( dev-java/blackdown-jdk )" # java? ( virtual/jdk )" RDEPEND="tcltk? ( dev-lang/tcl ) java? ( dev-java/blackdown-jre )" # java? ( virtual/jre )" ---- Reproducible: Always Steps to Reproduce: 1.USE="doc" emerge -pev system 2. 3. Actual Results: See sun-jdk required, by db-4.1.3 (causes a large tree of stuff to come in, as well) - see attached emerge -pev output Expected Results: Only required blackdown-jdk et. al. - see attached emerge -pev output with sys-libs/db-4.1.25_p1-r3 ebuild modified as described above. Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.7-hardened-r10 i686) ================================================================= System uname: 2.6.7-hardened-r10 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -pipe -O2" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.linux.ee/pub/gentoo/distfiles/ http://ftp.easynet.nl/mirror/gentoo/ http://ftp.heanet.ie/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acl acpi alsa apm arts avi berkdb bidi bitmap-fonts cdr crypt cups dhc-fqdn directfb dlloader doc dvd dvdr encode esd f77 faad fam flac foomaticdb fortran gcj gdbm gif gnome gpm gstreamer gtk gtk2 hardened imagemagick imlib java javamail jce jikes jpeg junit kde kerberos libg++ libwww mad mikmod mmx motif mozilla mpeg mpeg4 mysql ncurses nls odbc oggvorbis opengl oss pam pdflib perl pic pie png postgres python qt quicktime readline ruby samba sdl slang speex spell sse ssl svga tcltk tcpd tiff truetype trusted unicode usb wxwindows x86 xinerama xml2 xmms xv zlib linguas_en_GB linguas_de linguas_es linguas_it linguas_fr" (btw removing my portage overlay makes no difference)
Created attachment 43589 [details] emerge -pevt output, showing unexpected sun-jdk dependency
Created attachment 43590 [details] emerge -pevt output with blackdown forced for package db, sun-jdk no longer required
What does `emerge -pv virtual/jdk` say?
(this is after an emerge sync; i.e. the db ebuild is back to normal) -------- # emerge -pv virtual/jdk These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild Rf ] dev-java/sun-jdk-1.4.2.06 +doc +gnome +jce +kde +mozilla 0 kB Total size of downloads: 0 kB -------- Also, if it helps: -------- # find /usr/portage/profiles -exec grep -l sun-jdk \{\} \; /usr/portage/profiles/use.local.desc /usr/portage/profiles/default-ppc-1.0/packages /usr/portage/profiles/package.mask # find /etc/portage -exec grep -l sun-jdk \{\} \; # grep sun-jdk /var/lib/portage/* /var/lib/portage/world:dev-java/sun-jdk --------
If you have more than one virtual providing package installed, which one portage chooses is arbitrary and usually irrelevant. If you want to make a specific choice on what package to use for a specific virtual, you can do so by overriding portage's decisions in /etc/portage/virtuals.
If I specify "-e", I expect that portage should not be using anything about the installed system to determine dependencies. The emerge man page says of --emptytree, "Virtually tweaks the tree of installed packages to only contain libc". If portage is using other information about the already-installed system, then either the "-e" option is broken, or the man page is misleading. Setting the virtuals in /etc/portage/profile/virtuals didn't change a thing; "emerge -pevt system" still tries to emerge both jdks. Indeed I didn't expect it to - the profile (default-linux/x86/2004.3) already has blackdown-{jdk,jre} set for virtual/{jdk,jre}. Although the choice of virtual may usually be irrelevant, in this case it wasn't as the sys-libs/db-4.1.25_p1-r3 build worked with the blackdown-jdk but failed with the sun-jdk. It seems to me that the actual bug is that when '-e' is specified, the calculation of virtuals should be derived from only the profile, not the installed system. I've reopened, as the report is not invalid and the suggested workaround is not effective (and presumably "resolved" bugs don't get much attention :) ). "wontfix", "cantfix" or "later" would be appropriate if you don't intend to change anything.
/etc/portage/virtuals was the file to use to override. The order goes like this: * /etc/make.profile's parent (and its parent before that, etc) * /etc/make.profile * /etc/portage/profile * Installed Packages * /etc/portage You only need to touch /etc/portage/profile if you want to override the definition of what your default system is. Agreed on the documentation bug, though. That's been a long-standing bug actually. As you would have noticed, (g)libc is not virtually tweaked out of the tree either. How about something like: -e Reinstalls all world packages and their dependencies to the current USE specifications while differing from the installed set of packages as little as possible. It's not feasible for portage to ignore all installed packages when calculating dependencies. How to compile gcc if gcc is not installed? Mike, can you fix the docs to something to the effect of the above?
It was portage (emerge) that told me /etc/portage/virtuals was deprecated, and should be /etc/portage/profile/virtuals: *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) So I did what it told me, assuming the docs were just lagging behind the recent upgrades. Just tried /etc/portage/virtuals as originally suggested, and that does work (er, of course!). However, if it really is deprecated it'll stop working once it goes obsolete... I think I expected '-e' to give me the same that one would get doing an install from scratch as per the handbook with a livecd of the same profile. It occurs to me that where more than one package is installed that provides a virtual, there must always be a way of determining which is the default in use for the system, otherwise there'd be a mess. However portage won't necessarily make the same choice. Realistically, portage can't be expected to work that out in the general case, as it's specific to the set of packages providing the virtual - portage needs some assistance, either via direct hints or support within the ebuilds. The former is already available, obviously. Assuming /etc/portage/virtuals is not going to be made obsolete, but retained for the use of overriding as above (which seems sensible), perhaps it would be useful if portage were to suggest the user make an entry to resolve the ambiguity rather than choosing one apparently at random. It's not a blocking situation, so a warning (like the one about deprecated locations) could be sufficient, e.g. *** Multiple resolutions of virtual/jdk installed - choosing dev-java/sun-jdk *** To override this choice, add preferred resolution to /etc/portage/virtuals Just an idea. I'll guess that portage currently doesn't end up with a list to choose from (otherwise "emerge -pv virtual/jdk" would have listed both installed packages), but instead settles on the first one it finds (most recently installed?) so I appreciate it takes more than just adding a couple of ewarns!
For the most part, users shouldn't need to care about virtuals. Your case where portage wanted to install both blackdown-jdk and sun-jdk will be resolved in the next major version. It'll be mostly fixed in the next release of 2.0.51. The next version however will guarantee that one or the other will be installed unless there are specific dependencies on both.
Just to confirm, give the patch in bug #68220 a try and see what results you get then.
The patch made no difference to what portage gives for 'emerge -pevt system' - but I think it's not the same issue. When I said "both" in comment #6, that was careless and a mistake (sorry). Portage never tried to install both at the same time, for me the problem was it was choosing sun-jdk over blackdown-jdk, even though blackdown-jdk is the one in the profile. I have both installed, as I have some (probably nasty) java stuff that works only with blackdown and some that only works with sun. sun-jdk appears since it is in the world file, not because it's an explicit dependency from another package. I've just compared the "emerge -pevt world" output both with and without the patch, and there's no difference. My problem initially was that by forcing portage to choose blackdown-jdk, the emerge system built everything to completion without trouble. When portage was allowed to choose its own, and chose sun-jdk, the build failed, I think due to confusion, running a mix two java sdks. It was sys-libs/db-4.1.25_p1-r3 that failed to build, during the configure stage, right after emerge had built sun-jdk.
updated emerge(1)
