1 |
On Thu, 9 May 2002, George Shapovalov wrote: |
2 |
|
3 |
> On Thursday 09 May 2002 10:16, Bob Phan wrote: |
4 |
> > On Thu, 9 May 2002, Francisco Gimeno wrote: |
5 |
> > > and... going on work... we could make the same to the commands of the |
6 |
> > > ebuild packages, like dodir, doins, and those... to get them |
7 |
> > > well-documented and in an ordered way... |
8 |
> > |
9 |
> > I don't follow? The goal isn't to make an xml ebuild, as I rather |
10 |
> > like them as shell scripts and it lowers the bar a little for people |
11 |
> > that wan't to start writing their own. The design goels for what I |
12 |
> > suggested, is basically a way to keep track of all currently used USE |
13 |
> > vars. And basically, three things are important about each. |
14 |
> > |
15 |
> > 1) What they are called. |
16 |
> > 2) What they mean. |
17 |
> > 3) Which packages use them. |
18 |
> > |
19 |
> > I think it would be a valuable resource to have a maintainable and |
20 |
> > parsable list of these. As it stands, I already have a perl script |
21 |
> > that can dig out 1 & 2 and dump them into XML. I'm going to tidy it |
22 |
> > up a bit and probably post it to this group. |
23 |
> |
24 |
|
25 |
Please do not top-post. I moved it, and sorry about being picky. |
26 |
|
27 |
> Isn't there one already? |
28 |
> /usr/portage/profiles/use.desc |
29 |
> The format cannot be simpler: |
30 |
> usevar - description |
31 |
> Is there any problem with parsing that? Even cut -d "-" would do it (not to |
32 |
> mention awk and python). |
33 |
> This list is not enforced at present (that is if usevar is not listed there it |
34 |
> will still be considered valid), but that can change at any moment. |
35 |
|
36 |
As I said, I've already looked at it. And the format would be fine if |
37 |
it was actually enforced. Here are some outliars that I have found. |
38 |
|
39 |
trusted |
40 |
|
41 |
No dash, no description, not even a blank one. Therefor, you cannot |
42 |
tokenize based on dashes, since it is not gauranteed. Then you would |
43 |
think, why not tokenize based on newlines? Here's another one from |
44 |
that file. |
45 |
|
46 |
voodoo3 - Adds support for 3Dfx's Voodoo3 video chipset, else |
47 |
defaults to Voodoo4/5 support if not in USE |
48 |
|
49 |
That eliminates being able to tokenize based on newlines. Basically |
50 |
use.desc is really only useful for users. My suggestion would be to |
51 |
either clean this file up to conform to some form of guideline, or to |
52 |
make a mirror copy (ie _not_ to remove but to add in addition to) an |
53 |
XML file with the same information. |
54 |
|
55 |
> |
56 |
> As for the list of packages that use that var: that is going to be the largest |
57 |
> problem. This tends to be very dynamic, also I would be hesitant to put that |
58 |
> into use.desc as this will overload it (however technically this is very |
59 |
> simple: just add one more delimeter and then list packages using this var |
60 |
> (whitspace or comma separated)) |
61 |
> There was a discussion on introducing IUSE into ebuilds which is supposed to |
62 |
> list all use var that ebuild references. However there was not much activity |
63 |
> on that. Also it is just possible to scan ebuild for "use XX" clauses and |
64 |
> thus extract all referenced usevars. |
65 |
> I guess my point is that such back-reference list of packages referencing |
66 |
> usevars can easily be dynamically reconstructed, and that I think is better |
67 |
> solution than hand-maintained list. |
68 |
|
69 |
I've already written a script that can mine out all optional use |
70 |
statements. Adding the functionality to dynamically go backwards |
71 |
through the dependancy tree would be trivial. |
72 |
|
73 |
I just wanted to get a sense from all of you out there as to what you |
74 |
would vote for as a better standard for keeping a separate list with |
75 |
this information, which I or anyone can maintain. It would be really |
76 |
useful for a few scripts I've been meaning to write, such as a GTK+ |
77 |
based auto USE var generator. And a "what options are available to me |
78 |
in this ebuild before I install it" script. I'm also sure others |
79 |
would find some use for such information to be stored in a more usable |
80 |
format. |
81 |
|
82 |
-- |
83 |
/* |
84 |
* Bob Phan <bob@××××××××××××××××.net,rphan@××××.com> |
85 |
* Computational Chemistry Informatics |
86 |
* Neurogen Corporation |
87 |
* (203)488-8201 x4645 |
88 |
* |
89 |
* To understand recursion, you must first understand recursion. |
90 |
*/ |