I observed no effect from putting lines into /etc/portage/package.keywords. The attached patch fixes the problem.
Created attachment 54505 [details, diff] patch to correct logic error
what portage version is this against? Beyond that, a bit more info (test case) is usually useful...
package.keywords is used for augmenting *your* ACCEPT_KEYWORDS not for augmenting a package's KEYWORDS.
First off, sorry 'bout the lack of info. Here it is. I will respond to the second comment separately. Gentoo Base System version 1.6.10 Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.10-gentoo-r7 x86_64) ================================================================= System uname: 2.6.10-gentoo-r7 x86_64 AMD Opteron(tm) Processor 244 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 27 2005, 12:10:39)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.7.9-r1, 1.5, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.10-r3 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/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/X11/xkb /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="-O2 -pipe" DISTDIR="/archive/pub/linux/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distcc distlocks keeptemp keepwork noclean" GENTOO_MIRRORS="http://monster/pub/linux http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/archive/pub/linux/packages/amd64/" PORTAGE_TMPDIR="/usr/src" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://dragon/gentoo-portage" USE="amd64 X aalib acpi alsa avi bash-completion berkdb bitmap-fonts cdr codec cscope cups curl directfb divx4linux dvb dvd dvdread encode esd ethereal fam fbcon flac font-server fortran gdbm gif gphoto2 gpm gps gstreamer gtk gtk2 guile imagemagick imap imlib ipv6 jp2 jpeg junit ldap libg++ libwww lzw lzw-tiff mad maildir mailwrapper motif mozdevelop mozilla mp3 mpeg nas ncurses network nptl nptlonly nspr nvidia oav oci8 oggvorbis opengl pam pda pdflib perl pic png quicktime readline real samba savedconfig slang smime spell ssl tcltk tiff truetype truetype-fonts type1-fonts usb userlocales wmf xanim xinerama xml xml2 xmms xpm xrandr xv xvid xvmc zlib linguas_en_US" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
On the second issue, on rereading the portage manpage, you're right ... I was mistaken as to the intent of the file. My interpretation *seems* (at least to me) somewhat more intuitive, but then again, intuitive ain't everything ... if you build a system that even a fool could use, only a fool would want to use it. <G> I can think of one concrete advantage to the other way, which is that if one had an amd64 AND an alpha, he might be able to share a copy of packages.keywords between both machines, with one version of the same package marked as ~alpha, and another marked as ~amd64 ... Anyway, should I move this bug to verified? Regards and sorry, Rich
it's also useful for porters (they can accept other KEYWORDS while testing a package) or for cross-compiling
