Gentoo Archives: gentoo-portage-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check
Date: Wed, 17 Aug 2005 02:57:58
Message-Id: 200508171157.43595.jstubbs@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check by Brian Harring
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