On Wednesday 17 August 2005 11:34, Brian Harring wrote: > > 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).
The list of vars would definitely live in the ebuild. If the list of possibilities were to live in the tree, checks should only be done on whether an ebuild uses a var or not. I'd like the list of possibilities in the ebuild as well, personally, but I'd accept it in the tree as a compromise to getting this functionality in. > > 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. Again, it's a compromise. Thinking about it, though, it's probably not a very good compromise. If for some reason all ebuilds relying on a certain USE_EXPAND need to be updated, having the IUSE would serve well rather than having to fix ebuilds as they break. Much better from a QA standpoint... > > 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). Apart from it being more trouble that it's worth, I second this but have met with much resistance. I even wrote a patch to support it (bar the hiding of certain vars). Perhaps you should give convincing the masses a go? -- Jason Stubbs
pgpB04Ni4UiO2.pgp
Description: PGP signature
