1 |
"Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted |
2 |
200608122218.22034.volker.armin.hemmann@××××××××××××.de, excerpted below, |
3 |
on Sat, 12 Aug 2006 22:18:21 +0200: |
4 |
|
5 |
> On Saturday 12 August 2006 20:35, Duncan wrote: |
6 |
>> Peter Humphrey <prh@××××××××××.uk> posted |
7 |
>> 200608121835.43684.prh@××××××××××.uk, excerpted below, on Sat, 12 Aug |
8 |
>> |
9 |
>> > I disagree. It's easy enough for use.desc to say "This will pull in the |
10 |
>> > whole X-Window System" or "Enables programs to handle WMF files". Or even |
11 |
>> > just to include a single-letter G or L prefix to each description as a |
12 |
>> > first step. |
13 |
>> |
14 |
>> But the thing is, different packages may do different things with a USE |
15 |
>> flag. Support for X is often linking against xlib (as in the example I |
16 |
>> gave), but doesn't have to be that major, and (again as in the example) |
17 |
>> could be a minor as adding a few icons and *.desktop files. The only way |
18 |
>> to describe the effect of a USE flag on each package, in many cases, is to |
19 |
>> do just that, make the description per package, not global. |
20 |
> |
21 |
> so instead of a short but useful hint, which is enough in 95% of cases, |
22 |
> concentrated in two files, you want the user to search all packages and read |
23 |
> thousands of descriptions just to figure out if he wants the flag or not? |
24 |
> |
25 |
> Are you insane? |
26 |
|
27 |
Well, maybe =8^P, but I don't seem to be conveying what I'm trying to say |
28 |
accurately. No, I'm NOT saying search all packages and read thousands of |
29 |
descriptions (and agree, that could be considered insane, tho it's more or |
30 |
less what one has to do now)... |
31 |
|
32 |
> Oh, and for local-flags, there are several descriptions, have a look at ufed. |
33 |
> For the global ones 'pulls in X' or 'needed for mp3/wmv/avi support' is |
34 |
> really enough to know.It does not matter, that the single package does. I |
35 |
> want them to have wmv/mp3/X support, how they are do it, is the ebuild's |
36 |
> problem, not mine. I set a flag, the ebuild maintainer has to figure out how |
37 |
> to react to it. |
38 |
|
39 |
What I'm suggesting is that use.desc stay more or less as it is, with a |
40 |
general description for global USE flags. However, instead of |
41 |
use.local.desc only having non-global USE flags, have it list all flags |
42 |
(or split it into two or more files if it gets unmanageably huge) for all |
43 |
packages, with what they do for that package. |
44 |
|
45 |
For a quick idea of what the USE flag does in general, then, if it's a |
46 |
global USE flag, one would check the entry in use.desc which would be |
47 |
much as it is now. For a better idea of what it does in a particular |
48 |
package, check the corresponding entry in use.local.desc, which would |
49 |
describe the effects of the flag on that particular package. That's what |
50 |
I'm proposing. Users could just check the general description if that's |
51 |
all they wanted/needed, and have exactly the same level of info they have |
52 |
now, with a possible tweak to a description here or there. If they wanted |
53 |
to know for example what the gnome flag did in the pan package, however, |
54 |
they'd look in use.local.desc and see something to the effect of "Builds |
55 |
against libgnome to let pan use the configured gnome browser." |
56 |
|
57 |
See, the problem is that a flag, while it generally adds support for |
58 |
<flagfeature>, can mean very different things in different ebuilds. An |
59 |
example is the perl flag. In some ebuilds, it means build perl bindings. |
60 |
In others, it means install documentation for use with perl. In still |
61 |
others, it controls building optional package documentation that requires |
62 |
perl to build -- documentation for the package, not for using it with |
63 |
perl, but requiring perl to build that documentation. Those are three |
64 |
VERY different meanings, applying to different packages, with USE=perl |
65 |
used to control them. Having a per-package entry would allow the user to |
66 |
see precisely which of these the perl flag was used for in a particular |
67 |
package, or if it was used for something else entirely. There's simply no |
68 |
way to convey that with a global description, unless you effectively |
69 |
include the per-package descriptions right in the global description, of |
70 |
course making it long enough to do so, which would then leave us without a |
71 |
way to get a short and concise general description whet that's all that's |
72 |
needed. |
73 |
|
74 |
Still think it's insane, or did I actually convey the idea in a way that |
75 |
makes a bit more sense, now (whether you agree with it or not)? =8^) |
76 |
|
77 |
-- |
78 |
Duncan - List replies preferred. No HTML msgs. |
79 |
"Every nonfree program has a lord, a master -- |
80 |
and if you use the program, he is your master." Richard Stallman |
81 |
|
82 |
-- |
83 |
gentoo-amd64@g.o mailing list |