Bug 442830 – portage incorrectly filters USE_EXPAND for EAPIS 0-4, rather than just 5.

• Product: Portage Development
• Status: RESOLVED INVALID

[Description Brian Harring (RETIRED) 2012-11-11 23:35:41 UTC]

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.

[Comment 1 Zac Medico 2012-11-12 05:19:32 UTC]

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

[Comment 2 Brian Harring (RETIRED) 2012-11-12 06:06:24 UTC]

(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.

[Comment 3 Zac Medico 2012-11-12 06:24:49 UTC]

(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

[Comment 4 Zac Medico 2012-11-12 07:23:57 UTC]

(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.

[Comment 5 Brian Harring (RETIRED) 2012-11-12 07:30:29 UTC]

(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).

[Comment 6 Brian Harring (RETIRED) 2012-11-24 00:05:34 UTC]

Any activity going on here?  This is broken behaviour for <EAPI5 after all, and from a PMS standpoint needs some form of resolution....

[Comment 7 Michał Górny 2016-06-12 16:53:59 UTC]

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.