Bug 61984 – 2.0.51_pre20 doesnt respect virtual blockers with KEYWORDS=-* and `emerge ebuild`

• Product: Portage Development
• Status: VERIFIED TEST-REQUEST

[Description SpanKY 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-2.6.8.1: KEYWORDS="-*"

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

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

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

Portage 2.0.51_pre20 (default-ia64-1.4, gcc-3.3.2, glibc-2.3.4.20040619-r1, 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-2.14.90.0.8-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="ia64 ~ia64"
AUTOCLEAN="yes"
CFLAGS="-O2 -pipe"
CHOST="ia64-unknown-linux-gnu"
COMPILER=""
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"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache noauto nodoc noinfo noman sandbox"
GENTOO_MIRRORS="ftp://gentoo.oregonstate.edu/pub/gentoo"
MAKEOPTS="-j5"
PKGDIR="/root/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
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) 2004-09-08 21:19:14 UTC]

How does 2.0.50 react in this situation?

[Comment 2 SpanKY 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.3.4.20040619-r1, 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-2.6.8.1.ebuild -p | grep '^\['
[ebuild     U ] sys-kernel/linux26-headers-2.6.8.1 [2.6.7-r4]

[Comment 3 Jason Stubbs (RETIRED) 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) 2004-09-20 18:44:50 UTC]

Should be fixed in 2.0.51rc1

[Comment 5 SpanKY 2004-09-20 18:51:44 UTC]

seems to work well now, thanks

[Comment 6 Brandon Low (RETIRED) 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) 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.