Minimally since 2.1.11.9 in testing, portage is incorrectly scraping USE_EXPAND targets (say, PYTHON_TARGETS) down to just what IUSE intersects. Aka, it's applying profile-iuse-injection rules to all eapis, instead of just eapi5. This breaks w/ behaviour to say the least. Question is, what to do about it spec wise.
The current portage behavior dates back to this commit on 17 December 2007, released in portage-2.1.4: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=bbff2d84b034435756500be72ce167445f0f411c
(In reply to comment #1) > The current portage behavior dates back to this commit on 17 December 2007, > released in portage-2.1.4: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=bbff2d84b034435756500be72ce167445f0f411c Well... you say "current behavior"... USE_EXPAND filtering? USE filtering intersecting IUSE? Which? All of it? If we have to (again) change PMS retroactively, then we need to know exactly how portage has behaved here, when/if it switched. If it's literally been consistent the whole way back, I'd be inclined to just drop the conditional EAPI limiting for profile IUSE injection, and require it across all.
(In reply to comment #2) > Well... you say "current behavior"... USE_EXPAND filtering? USE filtering > intersecting IUSE? Which? All of it? All of it, essentially. The best reference is the config._get_implicit_iuse() method which was split out in the following commit, and still exists in current portage: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=594817e3704083bf8fe5ca606392d009b6fbf0f5 > If we have to (again) change PMS retroactively, then we need to know exactly > how portage has behaved here, when/if it switched. If it's literally been > consistent the whole way back, I'd be inclined to just drop the conditional > EAPI limiting for profile IUSE injection, and require it across all. I'll just paste the code here for reference (which hasn't changed since 2007/2008): def _get_implicit_iuse(self): """ Prior to EAPI 5, these flags are considered to be implicit members of IUSE: * Flags derived from ARCH * Flags derived from USE_EXPAND_HIDDEN variables * Masked flags, such as those from {,package}use.mask * Forced flags, such as those from {,package}use.force * build and bootstrap flags used by bootstrap.sh """ iuse_implicit = set() # Flags derived from ARCH. arch = self.configdict["defaults"].get("ARCH") if arch: iuse_implicit.add(arch) iuse_implicit.update(self.get("PORTAGE_ARCHLIST", "").split()) # Flags derived from USE_EXPAND_HIDDEN variables # such as ELIBC, KERNEL, and USERLAND. use_expand_hidden = self.get("USE_EXPAND_HIDDEN", "").split() for x in use_expand_hidden: iuse_implicit.add(x.lower() + "_.*") # Flags that have been masked or forced. iuse_implicit.update(self.usemask) iuse_implicit.update(self.useforce) # build and bootstrap flags used by bootstrap.sh iuse_implicit.add("build") iuse_implicit.add("bootstrap") # Controlled by FEATURES=test. Make this implicit, so handling # of FEATURES=test is consistent regardless of explicit IUSE. # Users may use use.mask/package.use.mask to control # FEATURES=test for all ebuilds, regardless of explicit IUSE. iuse_implicit.add("test") return iuse_implicit
(In reply to comment #3) > # Flags that have been masked or forced. > iuse_implicit.update(self.usemask) > iuse_implicit.update(self.useforce) This part can trigger some quirky behavior inside the _lazy_use_expand class, causing USE_EXPAND values to get filtered when there is any intersection with use.mask or use.force. It only affects EAPI 0-4 though, since EAPI 5 uses _calc_iuse_effective instead of _get_implicit_iuse.
(In reply to comment #4) > (In reply to comment #3) > > # Flags that have been masked or forced. > > iuse_implicit.update(self.usemask) > > iuse_implicit.update(self.useforce) > > This part can trigger some quirky behavior inside the _lazy_use_expand > class, causing USE_EXPAND values to get filtered when there is any > intersection with use.mask or use.force. It only affects EAPI 0-4 though, > since EAPI 5 uses _calc_iuse_effective instead of _get_implicit_iuse. Minor correction; non-involved USE_EXPAND groups are still pushed down into the build env (or at least into the final saved env); easy way to check, merge bsdiff, note ALSA_PCM_PLUGINS is in there. At least in my views/interpretation of PMS, this doesn't match the intention- minimally it doesn't match the overall intention of locking down the exposed USE to just what it is used (ie, deterministic builds).
Any activity going on here? This is broken behaviour for <EAPI5 after all, and from a PMS standpoint needs some form of resolution....
PMS does not define this, so there is no reason to force any specific behavior in Portage. In fact, it's more likely that we're going to unconditionally use EAPI 5+ behavior in all EAPIs, for consistency and therefore reduced user confusion.
