This is with portage-2.0.51-r3, the most recent according to a sync a few minutes ago. When I put text in /etc/portage/virtuals (as indicated in 'man profile'), I get this message from emerge: *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) However, if I move the file as indicated, the virtuals are ignored. E.g., if I put this in /etc/portage/profile/virtuals: virtual/linux-sources sys-kernel/gentoo-dev-sources virtual/alsa sys-kernel/gentoo-dev-sources and do emerge -p virtual/alsa, I get: These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild NS ] media-sound/alsa-driver-1.0.7-r4 which if course is wrong. But if I link /etc/portage/profile/virtuals to /etc/portage/virtuals, I get: *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-kernel/gentoo-dev-sources-2.6.9-r9 which feature annoying error messages but does the right thing. Reproducible: Always Steps to Reproduce: *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) *** /etc/portage/virtuals should be moved to /etc/portage/profile/virtuals *** Please correct this by merging or moving the file. (Deprecation notice) Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r1 i686) ================================================================= System uname: 2.6.9-gentoo-r1 i686 AMD Athlon(tm) XP 1900+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-g -O2" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/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 /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/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-g -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig distlocks fixpackages nostrip sandbox sfperms userpriv" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://gentoo.agsn.ca/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.ccccom.com ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib alsa apm arts avi berkdb bitmap-fonts canna cdr cjk crypt cups debug doc dvd encode esd f77 fam flac foomaticdb fortran freetype freewnn gdbm gif gnome gpm gtk gtk2 guile imagemagick imlib java joystick jpeg junit kde libg++ libwww mad maildir mbox mikmod mozilla mpeg mule ncurses nls noantlr nobcel nobeanutils nobsh nocommonslogging nocommonsnet nojdepend nojsch nojythonnolog4j nooro noregexp norhino noxalan noxerces oggvorbis opengl oss pam pdflibperl png python qt quicktime readline ruby scanner sdl slang speex spell sse ssl svga tcltk tcpd tetex tiff truetype usb x86 xinerama xml xml2 xmms xv zlib video_cards_matrox"
Hi, [ebuild NS ] media-sound/alsa-driver-1.0.7-r4 This means you already have another version of alsa-driver installed, right? /etc/portage/profile/virtuals works for me (with portage 2.0.51-r3 and 2.0.51-r8 both), but it only affects the default package to provide a virtual. If a virtual is already provided by another package, portage keeps using that. That's correct behaviour according to the documentation. However, for some reason, /etc/portage/virtuals will override this (I tested it with virtual/x11 and x11-base/xfree, while I have xorg-x11 installed). That, again according to the documentation, *is* a bug, but it's what you're hoping won't be fixed. Please let me know if I misunderstand something.
Yes, I want alsa-dirver to be installed for the 2.4 kernels. But I don't understand what you mean by "if a virtual is already provided by another package, portage keeps using that". The virtual is provided by multiple installed packages (alsa-driver and the gentoo-dev-sources), so why does portage think alsa-driver is the one providing it and not gentoo-dev-sources? I thought the whole point of /etc/portage/profile/virtuals was to let me tell it which one I want it to consider being used. If all it does is what you say (and 'man portage' does say that), it seems to me to be pretty useless---I can just install the one I want, so what good is having an obscure file to tell portage to do that for me?
"The virtual is provided by multiple installed packages (alsa-driver and the gentoo-dev-sources), so why does portage think alsa-driver is the one providing it and not gentoo-dev-sources?" It does this because there is not normally any reason to check if any other packages provide it as well. Normally, virtual/xxx is only used as a dependency, and when multiple packages provide the same virtual, there is (in that situation) no reason to check which package provides it, only that it's provided. If you don't mind me asking, why do you want to pass it as an argument to emerge directly? "I thought the whole point of /etc/portage/profile/virtuals was to let me tell it which one I want it to consider being used. If all it does is what you say (and 'man portage' does say that), it seems to me to be pretty useless---I can just install the one I want, so what good is having an obscure file to tell portage to do that for me?" It can be useful with injected packages (via emerge --inject or package.provided). For example, on my system, I added my kernel sources to /etc/portage/profile/package.provided, because I didn't use portage to install them. That doesn't tell portage I have virtual/alsa already. To solve that, I used /etc/portage/profile/virtuals to tell portage to use the kernel sources by default for that.
ASorry, I should have said in the original bug report. The original problem was that "emerge world" was attempting to emerge alsa-driver and stopping, preventing me from continuing the emerge (without hand intervention). I mentioned "emerge virtual/alsa" to demonstrate what was causing the problem. But because everything else is now up-to-date, I can no longer reproduce the problem that way. So I used "emerge virtual/alsa" in the bug report because it still tries to emerge alsa-driver (and is much easier to reproduce). Anyway, since emerge is doing the intended thing, I've changed the title to "/etc/portage/profile/virtuals should allow selection between installed providers of virtual/alsa" and changed the severity to "enhancement". (One actual bug is that "man portage" still refers to /etc/portage/virtuals, not /etc/portage/profile/virtuals.)
Created attachment 46743 [details, diff] virtuals-selection.patch "Sorry, I should have said in the original bug report. The original problem was that "emerge world" was attempting to emerge alsa-driver and stopping, preventing me from continuing the emerge (without hand intervention)." Then, masking newer versions of alsa-driver would probably be a better idea. But really, it's your system. This patch (against 2.0.51-r8) should do it. I tested it with virtual/editors, with nano, gvim and vim all installed. "Anyway, since emerge is doing the intended thing, I've changed the title to "/etc/portage/profile/virtuals should allow selection between installed providers of virtual/alsa" and changed the severity to "enhancement"." This patch (for me) doesn't noticeable slow down portage, and I don't believe it would break anything. However, it could be a real pain to keep supporting it if some functions are rewritten in later versions of portage, and it's only rarely useful, so perhaps it would be better to modify portage only on your local system. But that, of course, is completely the portage devs' choice :) "(One actual bug is that "man portage" still refers to /etc/portage/virtuals," I don't believe that's a bug, since portage still supports it (with a deprecation notice, but still). However, either the description for /etc/portage/virtuals is inaccurate, or the implementation is buggy, as explained earlier. "not /etc/portage/profile/virtuals.)" It does describe that. /etc/portage/profile/ is described as "site-specific overrides of /etc/make.profile/", and /etc/make.profile/virtuals is described.
An additional comment, I have emacs, vim and nano installed on my system, they all provide virtual/editor, but when I do emerge -e system (after upgrading gcc) portage wants to use emacs to satisfy the dependency. Since emacs depends on gnome and xorg lots of packages are remerged, when a better alternative would be to only remerge nano. The only way I've found to fix this is to either use the patch above or the deprecated /etc/protage/virtuals file.
/etc/portage/virtuals and /etc/portage/profile/virtuals have now been unified. Those files now override the profile in the same way that /etc/portage/prfoile/virtuals was doing already. Installed virtual-providing packages are then discovered and put in the same order as the stacked profile listing. This essentially means that /etc/portage/profile/virtuals can be used to both specify defaults and select among installed virtuals.
Also: Maybe /usr/lib/portage/bin/fixvirtuals should also update the virtuals at the right location, not /var/lib/dep/virtuals I think?
This is fixed in 2.0.51.19. The fixvirtuals scripts is outdated and doesn't apply to any of the 2.0.51 range. It will be removed on the next release.
