| 1 |
> As I said, I've already looked at it. And the format would be fine if |
| 2 |
Sorry, I did not notice that mentioned in original email. |
| 3 |
|
| 4 |
> it was actually enforced. Here are some outliars that I have found. |
| 5 |
I've corrected these two (added description to trusted and got rid of \n for |
| 6 |
voodoo3). |
| 7 |
|
| 8 |
> That eliminates being able to tokenize based on newlines. Basically |
| 9 |
> use.desc is really only useful for users. My suggestion would be to |
| 10 |
> either clean this file up to conform to some form of guideline, or to |
| 11 |
> make a mirror copy (ie _not_ to remove but to add in addition to) an |
| 12 |
> XML file with the same information. |
| 13 |
I would like to keep file format as simple as possible. It might be needed at |
| 14 |
some point to have a very basic function implemented that would be desirable |
| 15 |
in barebones system. It is not a good idea to have to include XML parsers |
| 16 |
just because one file needs to be parsed (thats the same reason as the one |
| 17 |
behind plain-text human readabla/easily parsable format for config files for |
| 18 |
majority of the apps). |
| 19 |
I think it is just a matter of enforcing certain use.desc format. As it stands |
| 20 |
now it can be parsed based on " - " key. I am going to raise this issue and |
| 21 |
suggest another separator (dash is used quite frequently in package names and |
| 22 |
some times in description). What do you think about "|"? Also ":" might be |
| 23 |
more logical, but it can naturally occure in description. |
| 24 |
|
| 25 |
|
| 26 |
> I've already written a script that can mine out all optional use |
| 27 |
> statements. Adding the functionality to dynamically go backwards |
| 28 |
> through the dependancy tree would be trivial. |
| 29 |
Nice, could you submit this script to bugs.gentoo.org? |
| 30 |
|
| 31 |
|
| 32 |
> I just wanted to get a sense from all of you out there as to what you |
| 33 |
> would vote for as a better standard for keeping a separate list with |
| 34 |
> this information, which I or anyone can maintain. It would be really |
| 35 |
I do not object the existence of such list. However I think it should not be |
| 36 |
hand-maintained. Since you will have a script which will fish for referenced |
| 37 |
use variables, better approach would be to have a tool that could generate |
| 38 |
this back-reference file per request. My experience with duplicating |
| 39 |
information is that things go insane if there is no defined authoritative |
| 40 |
entity and in this case collection of ebuilds clearly should take precedence. |
| 41 |
BTW similar tool can be used to check validity of use.desc. |
| 42 |
|
| 43 |
> useful for a few scripts I've been meaning to write, such as a GTK+ |
| 44 |
> based auto USE var generator. And a "what options are available to me |
| 45 |
> in this ebuild before I install it" script. I'm also sure others |
| 46 |
Neat, could you please create an appropriate bug on bugzilla, so things get |
| 47 |
registerd and your scripts will not get lost? I think at least some of them |
| 48 |
should make their way into gentoolkit. |
| 49 |
|
| 50 |
George |
Archives