media-libs/sdl-gfx does not have MMX assembler for amd64, thus does not compile (default-linux/amd64/2007.0/desktop profile). It is strange, that default-linux/amd64/package.use.mask contains (twice!) 'media-libs/sdl-gfx mmx', but portage still allows mmx for the package. Reproducible: Always Steps to Reproduce: 1.emerge -p sdl-gfx Actual Results: [ebuild R ] media-libs/sdl-gfx-2.0.13-r1 USE="mmx*" Expected Results: Mask 'mmx' USE flag for sdl-gfx, as defined in default-linux/amd64/package.use.mask. Portage 2.1.2-r9 (default-linux/amd64/2007.0/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.20-gentoo x86_64) ================================================================= System uname: 2.6.20-gentoo x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 24 Feb 2007 16:20:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /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/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub" LINGUAS="en sk" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 asf bash-completion bzip2 cairo caps cdr crypt cups dbus dga dri dts dv dvb dvd dvdr encode esd exif ffmpeg firefox flac foomaticdb gif glut gnome gstreamer gtk hal iconv idn imlib ipv6 jpeg mad mikmod mmx mmxext mng mono mp3 mpeg ncurses nls nptl ogg opengl pam pda pdf perl pic png ppds python readline scanner sdl spell sse sse2 ssl svg tiff timidity truetype udev unicode usb vcd vorbis wmf xinerama xml xprint xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en sk" USERLAND="GNU" VIDEO_CARDS="nv nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Dunno, it masks the flag just fine here when I stick it into package.use.mask
(In reply to comment #0) > media-libs/sdl-gfx does not have MMX assembler for amd64, thus does not > compile (default-linux/amd64/2007.0/desktop profile). It is strange, that > default-linux/amd64/package.use.mask contains (twice!) 'media-libs/sdl-gfx > mmx', but portage still allows mmx for the package. Because default-linux/amd64/2007.0/use.mask overrides it's parent profiles package.use.mask with -mmx.
So, either semantics of precedence of package.use.mask vs use.mask is wrong, or amd64 2007.0 profile is wrong? My opinion is that portage semantics should be changed that package.use.mask always overrides use.mask.
Correct, it should always override.
(In reply to comment #4) > Correct, it should always override. That's how it behaved in portage-2.1.1, but the behavior changed in portage-2.1.2 at the request of bug #151586. Both behaviors have their own merits. The primary justification for use.mask being allowed to override package.use.mask is that it prevents package.use.mask settings in a parent profile from overriding use.mask settings of a child profile. It just seems counter-intuitive that a parent profile would have the ability to override the settings of a child profile, thus the new behavior.
(In reply to comment #2) > Because default-linux/amd64/2007.0/use.mask overrides it's parent profiles > package.use.mask with -mmx. Yes. Is there any reason why the mmx flag isn't unmasked in default-linux/amd64/use.mask instead? That should solve the problem.
To expand on comment #6, if -mmx is moved from default-linux/amd64/2007.0/use.mask to default-linux/amd64/use.mask then it will solve the problem. The default-linux/amd64/package.use.mask entry will then override the use.mask entry within the same profile.
(In reply to comment #6) > Yes. Is there any reason why the mmx flag isn't unmasked in > default-linux/amd64/use.mask instead? That should solve the problem. There is. We cannot rely on people using other profiles then the 2007.0 having >=portage-2.1.2 installed, thus it could be that their portage would unmask the flag globally but not mask it for the individual packages.
Actually, until all profiles prior to 2007.0 are deprecated and the solution in comment #6 becomes feasable, we can copy the default-linux/amd64/package.use.mask to default-linux/amd64/2007.0/package.use.mask. That said, duplicating the same information sucks :(
Alternatively, you could create a default-linux/amd64/new/ profile that has the -mmx in use.mask and the package.* files. Then 2007.0 could inherit from ../new.
(In reply to comment #9) > That said, duplicating the same information sucks :( Yes, that is annoying. However, on the bright side, this only seems to be a transitional issue. When we start relying on multiple inheritance being available, there will be more options available to solve issues like this. Note that the ability of use.mask to override package.use.mask is not unique to use.mask/use.force. An identical stacking algorithm allows USE from make.defaults to override package.use from a parent profile.
*** Bug 168845 has been marked as a duplicate of this bug. ***
worked around by copying the package.use.mask along with a fat warning on the top Releng: Please make sure you update the profile in the snapshot too, or 2007.0 users will experience quite some problems.
