When pointing PORTAGE_CONFIGROOT to an alternate rootfs, package.mask gets sourced by emerge not only from $PORTAGE_CONFIGROOT/etc/make.profile, but also from the host's /usr/portage/profiles directory. This is undesirable/incorrect behavior for PORTAGE_CONFIGROOT; /usr/portage/profiles/package.mask shouldn't be sourced at all when PORTAGE_CONFIGROOT is set. I have a rootfs with a custom make.profile which doesn't inherit from existing Gentoo profiles. Included in this custom profile's "packages" file is the line: *dev-lang/swig Using portage-2.1_pre10-r2, I run the following command: # ACCEPT_KEYWORDS="~ppc" PORTAGE_CONFIGROOT=/root/embedded_rootfs ROOT=/root/embedded_rootfs emerge system Even though dev-lang/swig-1.3.27 is the latest swig and isn't masked by the custom profile's package.mask, emerge attempts to pull in version 1.3.25 instead. 1.3.27 is however masked in the host's package.mask. Editing /usr/portage/profiles/package.mask, I comment out the following line: =dev-lang/swig-1.3.27 I then run the above emerge command again and dev-lang/swig-1.3.27 gets pulled in as expected. Excerpt from an strace log of open() calls made by emerge, in order called: open("/root/embedded_rootfs/usr/local/overlays/portage/profiles/arcanux/package.mask", O_RDONLY) = 4 open("/root/embedded_rootfs/etc/portage/profile/package.mask", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/portage/profiles/package.mask", O_RDONLY) = 4 open("/root/embedded_rootfs/etc/portage/package.mask", O_RDONLY) = -1 ENOENT (No such file or directory) The offending line in portage.py seems to be: pkgmasklines = [grabfile_package(os.path.join(x, "package.mask")) for x in self.profiles] /usr/portage/profiles/package.mask is always in self.profiles, regardless of PORTAGE_CONFIGROOT setting.
$PORTDIR/profiles/package.mask isn't part of any profile. It's acutally package metadata that belongs to the package repository. Don'e let it's location in $PORTDIR/profiles/ fool you into thinking differently.
(In reply to comment #1) package.mask's role as repo metadata seems sane enough, despite its contextually ambiguous placement in $PORTDIR/profiles. In light of this, package.mask "pollution" is justified because you wouldn't want custom profiles blindly ignoring a repo's metadata. After further consideration I realize that $PORTAGE_CONFIGROOT/etc/make.profile/package.unmask would be an inappropriate place to override $PORTDIR/profiles/package.mask; this would more properly be done under $PORTAGE_CONFIGROOT/etc/portage. I no longer see a case for this bug so I'm marking it WONTFIX.
