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 |