| 1 |
Isn't there one already? |
| 2 |
/usr/portage/profiles/use.desc |
| 3 |
|
| 4 |
The format cannot be simpler: |
| 5 |
usevar - description |
| 6 |
Is there any problem with parsing that? Even cut -d "-" would do it (not to |
| 7 |
mention awk and python). |
| 8 |
This list is not enforced at present (that is if usevar is not listed there it |
| 9 |
will still be considered valid), but that can change at any moment. |
| 10 |
|
| 11 |
As for the list of packages that use that var: that is going to be the largest |
| 12 |
problem. This tends to be very dynamic, also I would be hesitant to put that |
| 13 |
into use.desc as this will overload it (however technically this is very |
| 14 |
simple: just add one more delimeter and then list packages using this var |
| 15 |
(whitspace or comma separated)) |
| 16 |
There was a discussion on introducing IUSE into ebuilds which is supposed to |
| 17 |
list all use var that ebuild references. However there was not much activity |
| 18 |
on that. Also it is just possible to scan ebuild for "use XX" clauses and |
| 19 |
thus extract all referenced usevars. |
| 20 |
I guess my point is that such back-reference list of packages referencing |
| 21 |
usevars can easily be dynamically reconstructed, and that I think is better |
| 22 |
solution than hand-maintained list. |
| 23 |
|
| 24 |
George |
| 25 |
|
| 26 |
|
| 27 |
On Thursday 09 May 2002 10:16, Bob Phan wrote: |
| 28 |
> On Thu, 9 May 2002, Francisco Gimeno wrote: |
| 29 |
> > and... going on work... we could make the same to the commands of the |
| 30 |
> > ebuild packages, like dodir, doins, and those... to get them |
| 31 |
> > well-documented and in an ordered way... |
| 32 |
> |
| 33 |
> I don't follow? The goal isn't to make an xml ebuild, as I rather |
| 34 |
> like them as shell scripts and it lowers the bar a little for people |
| 35 |
> that wan't to start writing their own. The design goels for what I |
| 36 |
> suggested, is basically a way to keep track of all currently used USE |
| 37 |
> vars. And basically, three things are important about each. |
| 38 |
> |
| 39 |
> 1) What they are called. |
| 40 |
> 2) What they mean. |
| 41 |
> 3) Which packages use them. |
| 42 |
> |
| 43 |
> I think it would be a valuable resource to have a maintainable and |
| 44 |
> parsable list of these. As it stands, I already have a perl script |
| 45 |
> that can dig out 1 & 2 and dump them into XML. I'm going to tidy it |
| 46 |
> up a bit and probably post it to this group. |
Archives