Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND)
Date: Tue, 27 Sep 2005 14:23:39
Message-Id: 200509272320.59548.jstubbs@gentoo.org
In Reply to: Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND) by Chris Gianelloni
1 On Tuesday 27 September 2005 21:35, Chris Gianelloni wrote:
2 > On Tue, 2005-09-27 at 18:23 +0900, Jason Stubbs wrote:
3 > > 1) What to do if nothing is set?
4 > > 2) What to do if an invalid value is set?
5 >
6 > Install everything. If everything cannot be installed, due to
7 > incompatibilities, then die.
8
9 This causes trouble though as it has in your case below.
10
11 > > Of these, 1) and 2) absolutely must be whittled down to one standard.
12 > > Preferably, 3) should follow one standard as well. Not following one
13 > > standard will simply lead to users thinking, "but that's not what I
14 > > wanted..!" It will also lead portage to do needless recompiles due to the
15 > > information available being limited.
16 > >
17 > > Next, storing the information of what choices are valid. If it can be
18 > > guaranteed that all packages supporting a variable (LINGUAS for example)
19 > > have exactly the same list of choices in all cases, storing the choice
20 > > list in a global file is acceptable. If not, each package absolutely must
21 > > list what choices are available for it. Not doing so means the flow may
22 > > head into 2) in the above list even when the user has set a valid choice
23 > > for a different package. Again, it's against the user's expectations.
24 >
25 > Let's take an example of this... Neverwinter Nights. Currently, it
26 > installs the language packs via LINGUAS. If nothing is selected via
27 > LINGUAS, then it installs English, which is considered the default.
28 > Unfortunately, even trying to add -linguas_fr to package.use, still
29 > results in the French language pack being installed over the English. I
30 > honestly do not know how to correct this. I see a couple things that
31 > would be needed. For one, things in USE_EXPAND would need to be
32 > negate-able in package.use. The problem with NWN is that only one
33 > language pack may be installed at any given time due to them providing
34 > the same files.
35
36 The current implementation extends the USE flags with those derived from
37 USE_EXPAND after everything has been cascaded. It was likely done this way
38 out of ease of implementation, but now that USERLAND and such are using it...
39
40 > I would love to see this fixed. I'm guessing that this would mean
41 > defining all of the USE_EXPAND capabilities in IUSE, correct?
42
43 That is one solution that isn't hard to support, can be done quickly(?) on the
44 ebuild side and is already implemented (though unreleased) on the portage
45 side. However, it really seems to me that USE_EXPAND just doesn't expand well
46 (pardon the pun ;). Thinking about it, USE has its own set of issues as well.
47 There are number of cases in the tree of "you can have A or B, but not both"
48 and "you must pick at least A or B". There's also "if A isn't set then B and
49 C aren't used".
50
51 Long term solution would seem to be to completely revamp the
52 USE/USE_EXPAND/ARCH-USERLAND-* system to clear out at least the existing
53 pitfalls and hopefully not fall into new ones (and of course maintain
54 backward compatibility). If there's agreement in that, it might not be the
55 best bet to put a whole lot of work into getting USE_EXPAND working
56 "correctly"; that is to say, getting things following the above rules is
57 perhaps not worth the effort.
58
59 As it stands, it would seem package.env support, a way to express dependencies
60 between USE flags, a way to express USE_EXPAND choices, a way to express
61 limits on those choices and a way to protect profile variables (just to begin
62 with) are all required to get the current system working a bit more smoothly.
63 Seems very much like a bandaid on a bandaid on a ...
64
65 Bah.. I'm mumbling. I really don't mind what the solution is in the short term
66 as long as the USE_EXPAND choices get delivered to the users and that how
67 those choices work is clear. If the solution I've already done a patch for
68 isn't acceptable to everyone, find a solution that is and I'll support it
69 accordingly. I just don't want it to sit around and gather more dust.
70
71 --
72 Jason Stubbs
73 --
74 gentoo-dev@g.o mailing list