Re: [gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check

[Brian Harring]

On Wed, Aug 17, 2005 at 10:41:12AM +0900, Jason Stubbs wrote:
> You hijacked a thread again...
Bleh, headers (yes I've been lazy and just hitting reply on previous 
messages to lift the to :P)


> On Wednesday 17 August 2005 09:52, Brian Harring wrote:
> > basically, use_expand'd vars need to be exempted from IUSE checks, as
> > long as the USE_EXPAND var is in IUSE.
>
> I don't really like the idea of this without a companion patch that provides
> some way to get a list of relevant env vars and their possible settings to
> the user without having to look at the ebuild. The list of possiblities
> could live in use.desc or a similar file, but at minimum the list of vars
> needs to be provided.
Fix in the meantime since people are poking about it; a proper lock 
down of IUSE makes sense, exempting 
A) addition of Yet Another File To Profiles
B) if you do it within portdir (as per the norm), it effectively 
   changes IUSE for all ebuilds viewed, meaning QA complaints in binpkgs 
   and overlay ebuilds (where it may be valid in that context).

> Another patch is also required that will allow disabling of the QA check on
> certain vars, preferably defined in a file in the tree similar to
> info_vars. This would be used for vars such as USERLAND which are profile
> defined.
Why whitelist some vars, but not others?  If you're locking the 
USE_EXPAND'd vars down for full IUSE check, any profile defined var 
should be limited in the same way, imo.  A var not used in a profile 
is effectively dead ebuild code, even if the profile has disappeared; 
that said, still suffers the same issues as B above.

> In other words, don't kill the QA check without addressing the issue that
> the QA check is warning about. ;)
Issues above kind of strike me as it being more trouble then worth- 
personally, I'd rather see IUSE for that ebuild have the known 
USE_EXPAND'd var variations it uses listed, with some form of 
filtering to keep people from attempting dumb things like userland_BSD 
when they're on userland_GNU (hypothetical example).
~harring