Once again the Council is asked [1] to confirm that Portage is supposed to comply with PMS. In this case, it is about the patch fixing USE_EXPAND support [2], since it is a well-known fact that a pile of hacks that is impossible to figure out what it does exactly is arguably better than following the standards. [1]:https://archives.gentoo.org/gentoo-portage-dev/message/1c5724058e4f484f3a76ba787d15cdc3 [2]:https://archives.gentoo.org/gentoo-portage-dev/message/42e3a134d14e33e037e35e6c5df9d05d
@council: Is this change in behavior desirable at this stage, given the way that it affects the existing ebuilds out there (including those in the official gentoo repository)? We can't just make changes like this without considering the consequences.
Why did you agree to the wording we discussed for the spec, and then ignore it when implementing it? This isn't a case of "PMS didn't describe existing behaviour": it's "we agreed on how all this would work, and then you implemented something else"...
(In reply to Ciaran McCreesh from comment #2) > Why did you agree to the wording we discussed for the spec, and then ignore > it when implementing it? Subconscious passive aggression, maybe? > This isn't a case of "PMS didn't describe existing > behaviour": it's "we agreed on how all this would work, and then you > implemented something else"... Well, I'm not necessarily opposed to fixing it now. I just want people to consider all of the consequences first.
The wording of the spec is quite clear here: https://projects.gentoo.org/pms/6/pms.html#x1-11900011.1.1 "For EAPIs listed in table 5.2 as supporting profile defined IUSE injection [i.e., EAPIs 5 and 6], the variables named in USE_EXPAND and USE_EXPAND_UNPREFIXED shall have their profile-provided values reduced to contain only those values that are present in IUSE_EFFECTIVE." Since the feature was introduced with an EAPI bump, I am surprised that Portage doesn't implement it according to specification. Anyway, seems that the damage in form of non-compliant ebuilds in the tree is already done. Is it possible to follow the same procedure as in similar cases, namely make it a QA warning for some time, before Portage behaviour will be tightened?
You can't really detect when some random subprocess happens to be accessing an environment variable that should be empty but isn't.
(In reply to Ciaran McCreesh from comment #5) > You can't really detect when some random subprocess happens to be accessing > an environment variable that should be empty but isn't. That's true, of course ...
Well, we could make Portage through a QA warning for every USE_EXPAND that isn't used by a particular ebuild. I'm sure this will bring some attention to all those global flags that are used on single packages.
Zac agreed that this patch can be applied once LINGUAS problem is resolved, as currently handled.
