Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 61984 - 2.0.51_pre20 doesnt respect virtual blockers with KEYWORDS=-* and `emerge ebuild`
Summary: 2.0.51_pre20 doesnt respect virtual blockers with KEYWORDS=-* and `emerge ebu...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
Depends on:
Reported: 2004-08-27 16:54 UTC by SpanKY
Modified: 2004-09-22 17:53 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2004-08-27 16:54:08 UTC
currently linux26-headers is KEYWORD-ed like this:
linux26-headers-2.6.7-r4: KEYWORDS="-* ~x86 ~ppc ~arm ~hppa ~amd64 ~ia64"
linux26-headers- KEYWORDS="-*"

they both have PROVIDE/DEPEND lines:
PROVIDE="virtual/kernel virtual/os-headers"

in the normal course of things, this works fine ... however, i was on ia64 and tried to do `emerge linux26-headers-` but it failed due to the blocker:
[blocks B     ] sys-kernel/linux26-headers (from pkg sys-kernel/linux26-headers- 
[ebuild     U ] sys-kernel/linux26-headers- [2.6.7-r4]

but if i added 'ia64' to's KEYWORDS and did `emerge linux26-headers -p`, it didnt give me a blocker:
[ebuild     U ] sys-kernel/linux26-headers- [2.6.7-r4]

Portage 2.0.51_pre20 (default-ia64-1.4, gcc-3.3.2, glibc-, 2.6.9-rc1 ia64 )
System uname: 2.6.9-rc1 ia64 
Gentoo Base System version 1.5.3
distcc 2.17 ia64-unknown-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
Binutils: sys-devel/binutils-
Headers:  sys-kernel/linux26-headers-
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="ia64 ~ia64"
CFLAGS="-O2 -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe"
FEATURES="autoaddcvs ccache noauto nodoc noinfo noman sandbox"
USE="X crypt cups encode foomaticdb gdbm gif gnome gpm gtk gtk2 ia64 imlib jpeg kde libg++ libwww mikmod motif mysql ncurses oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype xml2 xmms xv zlib"
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2004-09-08 21:19:14 UTC
How does 2.0.50 react in this situation?
Comment 2 SpanKY gentoo-dev 2004-09-08 21:34:38 UTC
2.0.50-r11 seems to handle it fine:

i2 linux26-headers # emerge --version
Portage 2.0.50-r11 (default-ia64-1.4, gcc-3.3.2, glibc-, 2.6.9-rc1)
i2 linux26-headers # emerge linux26-headers -p | grep '^\['
[ebuild   R   ] sys-kernel/linux26-headers-2.6.7-r4  
i2 linux26-headers # emerge linux26-headers- -p | grep '^\['
[ebuild     U ] sys-kernel/linux26-headers- [2.6.7-r4]
Comment 3 Jason Stubbs (RETIRED) gentoo-dev 2004-09-09 05:37:31 UTC
-- portage-2.0.50-r10 --
if (myparent):
    if myparent.split()[2] in portage.portdb.xmatch("match-all", x[1:]):

-- portage-2.0.50-r20 --
if (myparent):
    if myparent.split()[2] in portage.portdb.xmatch("list-visible", x[1:]):

The latter causes this bug. The former causes the same problem to occur when using --upgradeonly except that the package blocks itself down to the version component. This has been reversed in CVS already (due to this bug - just forgot to report) which means --upgradeonly won't work.

I didn't understand the "list-visible" fix - Nakano did it - but there is probably a better way to fix the --upgradeonly problem.
Comment 4 Jason Stubbs (RETIRED) gentoo-dev 2004-09-20 18:44:50 UTC
Should be fixed in 2.0.51rc1
Comment 5 SpanKY gentoo-dev 2004-09-20 18:51:44 UTC
seems to work well now, thanks
Comment 6 Brandon Low (RETIRED) gentoo-dev 2004-09-22 16:22:02 UTC
Hmm... in 2051rc1 using -K, I get the blocking itself down to the version issue...  Thoughts?
Comment 7 Jason Stubbs (RETIRED) gentoo-dev 2004-09-22 17:53:07 UTC
If the binary package does not have a corresponding ebuild, then it will block on itself regardless of the above change. Either way, please open a new bug.