1 |
Jason Rhinelander wrote: |
2 |
> > I whole-heartedly agree with the premise of "putting some order into |
3 |
> > it". I still think part of that needs to be some sort of clear |
4 |
> > documentation. 'mozilla +java' is pretty clear, but 'xfree +xml2' just |
5 |
> > says to me "why does xfree need xml2, what does it do for it, and what |
6 |
> > would happen if I didn't include it?". There needs to be some sort of |
7 |
> > clear descriptions (optimally per-package) that allow people to make |
8 |
> > informed decisions about which flags to include and which they can |
9 |
> > safely discard. |
10 |
> |
11 |
> It seems to me that a far better approach is the idea of per-package use |
12 |
> flags, with some documentation in the package - so that something like |
13 |
> ``emerge -pvv packagename'' would show me not only which use flags are |
14 |
> in effect, but what they do to the package. |
15 |
> |
16 |
> So, yes to better (i.e. per-package) documentation, but no to exploding |
17 |
> use flags 5 or 6 ways each. |
18 |
> |
19 |
> For documentation, I suggest something like the following: |
20 |
> |
21 |
> Inside abc-xyz/packagename-1.2.3-r4.ebuild: |
22 |
> ... |
23 |
> IUSE="aaa bbb ccc" |
24 |
> |
25 |
> WHYIUSE="aaa - gives you aaa client support |
26 |
> bbb - gives you bbb server support |
27 |
> ccc - makes <package> do strange and unusual things with ccc" |
28 |
> ... |
29 |
> |
30 |
> Then, when I, Gentoo User, run: |
31 |
> |
32 |
> # emerge -pv packagename otherpackage |
33 |
> |
34 |
> I'll see (nothing new): |
35 |
> |
36 |
> These are the packages that I would merge, in order: |
37 |
> |
38 |
> Calculating dependencies ...done! |
39 |
> [ebuild N ] abc-xyz/packagename-1.2.3-r4 +aaa -bbb -ccc |
40 |
> [ebuild N ] abc-xyz/otherpackage-4.3.2-r1 +gnome -curses +cgi |
41 |
> |
42 |
> "Ah, that's interesting," I think to myself "I wonder what the cgi use |
43 |
> flag does for 'otherpackage'?" So I run: |
44 |
> |
45 |
> # emerge -pvv packagename otherpackage |
46 |
> |
47 |
> and I see: |
48 |
> |
49 |
> These are the packages that I would merge, in order: |
50 |
> |
51 |
> Calculating dependencies ...done! |
52 |
> [ebuild N ] abc-xyz/packagename-1.2.3-r4 +aaa -bbb -ccc |
53 |
> aaa - gives you aaa client support |
54 |
> bbb - gives you bbb server support |
55 |
> ccc - makes packagename do strange and unusual things with ccc" |
56 |
> [ebuild N ] abc-xyz/otherpackage-4.3.2-r1 +gnome -curses +cgi |
57 |
> gnome - adds gnome control center support |
58 |
> curses - adds curses management support |
59 |
> cgi - gives you management support via an installed CGI script |
60 |
> |
61 |
> |
62 |
> I think the above would be a VERY useful thing, at least once use flags |
63 |
> are sorted out - but the sorting out that needs to happen is making use |
64 |
> flags per-package, not to go in the direction of giving every package |
65 |
> its own set of use flags. |
66 |
|
67 |
You read my mind. Here's what I posted on -doc earlier today (I don't |
68 |
know if it got through to -dev or not): |
69 |
|
70 |
"I guess the obvious place for this information would be inside the |
71 |
ebuild itself. It could get be parsed out for the packages page. An |
72 |
example ebuild (gcc) would have: |
73 |
|
74 |
USE_DESC="java: compiles the gcj java compiler and associated support |
75 |
files; not needed if you're not using gcj" |
76 |
|
77 |
That would put a small additional load on ebuild creators, yes, but who |
78 |
knows their USE flags better than the ebuilders themselves? That short |
79 |
one-liner would be extremely helpful on my (the user's) end as well. I'd |
80 |
see that (either by looking at packages.gentoo.org, or in the ebuild, or |
81 |
with etcat, or similar) and say "Ok, I don't think I'm ever going to use |
82 |
gcj, so I'll set USE="-java" without worrying about unintended |
83 |
consequences." |
84 |
|
85 |
-- |
86 |
Joel Konkle-Parker |
87 |
Webmaster [Ballsome.com] |
88 |
|
89 |
Phone [+1 662-518-1636] |
90 |
E-mail [jjk3@×××××××.edu] |