1 |
Jason Stubbs posted <200509231019.16895.jstubbs@g.o>, excerpted |
2 |
below, on Fri, 23 Sep 2005 10:19:14 +0900: |
3 |
|
4 |
> On Friday 23 September 2005 05:28, Tom Fredrik Blenning Klaussen wrote: |
5 |
>> Now as for the USE flag system. It has actually become so big that it's |
6 |
>> difficult to use it effectively. I would actually suggest that a two |
7 |
>> level system of USE flags could be employed. Something like |
8 |
>> wtk/gtk (Windowing Toolkit / gtk) |
9 |
>> wtk/kde (Windowing Toolkit / kde) |
10 |
> |
11 |
> This is just arbitrary grouping as far as USE flags themselves go. Rather |
12 |
> than changing the name of the flags, why not just split the flags that are |
13 |
> in use.desc into categories separated by comments? |
14 |
> |
15 |
> # some category |
16 |
> use ... |
17 |
> use ... |
18 |
> ... |
19 |
> |
20 |
> # Windowing Toolkits |
21 |
> gtk ... |
22 |
> kde ... |
23 |
> |
24 |
> # some other category |
25 |
> ... |
26 |
|
27 |
The problem as I see it with comment-categories for USE flags is that it |
28 |
doesn't well match how USE flags (and looking up USE flag descriptions) |
29 |
are actually used. |
30 |
|
31 |
TFBKlaussen's proposal would make it immediately obvious from an emerge |
32 |
--verbose --ask (or --pretend) what category was involved. Commenting |
33 |
use.desc (and use.local.desc) doesn't have that advantage. |
34 |
|
35 |
Additionally, when I look up a description, it's usually by grepping |
36 |
use.(local.)desc, and I suppose many others work similarly. I/we don't |
37 |
care about all the /other descriptions, only the one we are wondering |
38 |
about. Putting additional information in a comment line ?? lines above |
39 |
the flag and description in question would /not/ be helpful. OTOH, using |
40 |
a category/flag arrangement would be somewhat of a description of its own, |
41 |
meaning the description could be shortened, and the line would be no |
42 |
longer than it is currently. (With 80-char screen widths, this can be an |
43 |
issue.) |
44 |
|
45 |
OTOH, it's obviously yet /another/ thing for portage devs to work on, and |
46 |
portage is /supposed/ to be in feature request freeze ATM... I like the |
47 |
idea, but whether the benefits of putting it on the current feature list |
48 |
outweigh the costs of putting it off, is something I'm not going to even |
49 |
pretend I want to evaluate. =8^| If you portage devs believe it's easy |
50 |
to "make it so", perhaps further discussion is warranted. If not, I'm |
51 |
not in favor of putting off the next portage yet /again/ to make it |
52 |
happen, tho it'd certainly be nice to have, so I'd say it's not even worth |
53 |
further discussion ATM. JMHO... |
54 |
|
55 |
-- |
56 |
Duncan - List replies preferred. No HTML msgs. |
57 |
"Every nonfree program has a lord, a master -- |
58 |
and if you use the program, he is your master." Richard Stallman in |
59 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
60 |
|
61 |
|
62 |
-- |
63 |
gentoo-dev@g.o mailing list |