1 |
On Wednesday 17 August 2005 11:34, Brian Harring wrote: |
2 |
> > I don't really like the idea of this without a companion patch that |
3 |
> > provides some way to get a list of relevant env vars and their possible |
4 |
> > settings to the user without having to look at the ebuild. The list of |
5 |
> > possiblities could live in use.desc or a similar file, but at minimum |
6 |
> > the list of vars needs to be provided. |
7 |
> |
8 |
> Fix in the meantime since people are poking about it; a proper lock |
9 |
> down of IUSE makes sense, exempting |
10 |
> A) addition of Yet Another File To Profiles |
11 |
> B) if you do it within portdir (as per the norm), it effectively |
12 |
> changes IUSE for all ebuilds viewed, meaning QA complaints in binpkgs |
13 |
> and overlay ebuilds (where it may be valid in that context). |
14 |
|
15 |
The list of vars would definitely live in the ebuild. If the list of |
16 |
possibilities were to live in the tree, checks should only be done on |
17 |
whether an ebuild uses a var or not. I'd like the list of possibilities in |
18 |
the ebuild as well, personally, but I'd accept it in the tree as a |
19 |
compromise to getting this functionality in. |
20 |
|
21 |
> > Another patch is also required that will allow disabling of the QA |
22 |
> > check on certain vars, preferably defined in a file in the tree similar |
23 |
> > to info_vars. This would be used for vars such as USERLAND which are |
24 |
> > profile defined. |
25 |
> |
26 |
> Why whitelist some vars, but not others? If you're locking the |
27 |
> USE_EXPAND'd vars down for full IUSE check, any profile defined var |
28 |
> should be limited in the same way, imo. A var not used in a profile |
29 |
> is effectively dead ebuild code, even if the profile has disappeared; |
30 |
> that said, still suffers the same issues as B above. |
31 |
|
32 |
Again, it's a compromise. Thinking about it, though, it's probably not a |
33 |
very good compromise. If for some reason all ebuilds relying on a certain |
34 |
USE_EXPAND need to be updated, having the IUSE would serve well rather than |
35 |
having to fix ebuilds as they break. Much better from a QA standpoint... |
36 |
|
37 |
> > In other words, don't kill the QA check without addressing the issue |
38 |
> > that the QA check is warning about. ;) |
39 |
> |
40 |
> Issues above kind of strike me as it being more trouble then worth- |
41 |
> personally, I'd rather see IUSE for that ebuild have the known |
42 |
> USE_EXPAND'd var variations it uses listed, with some form of |
43 |
> filtering to keep people from attempting dumb things like userland_BSD |
44 |
> when they're on userland_GNU (hypothetical example). |
45 |
|
46 |
Apart from it being more trouble that it's worth, I second this but have met |
47 |
with much resistance. I even wrote a patch to support it (bar the hiding of |
48 |
certain vars). Perhaps you should give convincing the masses a go? |
49 |
|
50 |
-- |
51 |
Jason Stubbs |