Bugzilla Bug 52160

see attachment for an ebuild that is guilty of this-

basically,
IUSE="blah"
inherit x y z
$IUSE != "blah"

If this is a design decission, this ought to be noted in the changelog, since it is a change of existing ebuild support.


Reproducible: Always
Steps to Reproduce:
1. dl attached ebuild
2. emerge -vp ebuild

Actual Results:  
note the lack of Use vars :)


Like I said, if this is intentional, it ought to be documented that it's now strictly enforcing it.
I haven't done a scan of the tree to track down ebuilds that would be affected, but the attached 
example was in the tree (and is how I noticed this behaviour)..

Created an attachment (id=32117) [edit]
mplayer-1.0_pre4-r3.ebuild

noted IUSE above inherit.  the version in the tree will have IUSE below
inherit, hence this attachment.

Created an attachment (id=32118) [edit]
ebuild.sh patch preserving vars

patch again vanilla 2.0.51_pre9 ebuild.sh.

Pretty straightforward tweak, makes B_IUSE, B_*DEPEND local variables to the
inherit function, keeping multiple invocations of inherit() from wiping the
vars; recursive-safe. 

(1) DEPEND stuff is already handled properly, no reason to preserve it like
this
(2) inherit should always come first ... i thought i had documented this, guess
not ... i'll add it to policy
(3) i do agree that some variables should be accumulative like USE is for the
environment ... IUSE/RESTRICT are two such variables i would like to see with
this behavior

Changing summary, checked the .50-r7 src, and the inherit issue is still there.
Another set of ebuilds affected by this are sys-dev/gcc-*

*** Bug 53257 has been marked as a duplicate of this bug. ***

*** Bug 53282 has been marked as a duplicate of this bug. ***

portage-2.0.50-r8 has been stabled w/ this fix.

According to Breach in #gentoo-portage and my own tests with -r8 this is not
fixed. The patch is there, but inherit still resets IUSE,

Created an attachment (id=32941) [edit]
portage-2.0.50-r8-iuse-fix.patch

*cough*.
Yeah, feel free to kick me in the head- the fix was originally for .51. 
Problem is .51's inherit (ebuild.sh in general) changed a bit, eclass defined
IUSE vars are set to IUSE in .50, no shifting of the original value into a
temporary holding variable to avoid being squashed.

That's why .50-r8 isn't behaving, the inherit fix doesn't even affect it since
.50 doesn't *try* to protect IUSE a tall-
meanwhile, I've grabbed the necessary IUSE protection out of .51, and exported
them back.  Taken it for a test spin, eclass IUSE settings are coming through
along w/ the ebuild's IUSE definition, so it should fix things.

no longer an issue in .51, issue in .50 still.

Still's an issue in 2.0.50-r9.

*** Bug 57304 has been marked as a duplicate of this bug. ***

*** Bug 60420 has been marked as a duplicate of this bug. ***

*** Bug 45742 has been marked as a duplicate of this bug. ***

Included in .50-r10, has been in .51 for a while.