[gentoo-dev] Parsable list of all use variables.

[gentoo-dev] Parsable list of all use variables.

[Bob Phan]

I think it would be a good idea for someone (I could do this if no one
wants to) to maintain a parsable list of all the use variables, what
they are for, and which ebuilds use them.  This would be useful for
writing tools that would want to know this information, or even for
automatic maintenence of a webpage for use variables.  CSV or XML
would be a good format for this.  XML may be overkill, expecially for
someone wanting to write a shell script with acess to this
information, but XML would also work great for c, perl, python, and
web maintenence.

I have taken a look at /usr/portage/profiles/use.desc,
and while useful for users to read, it is not easily parsable.

Any thoughts, suggestions?

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1961 bytes --]

On Thu, 9 May 2002, Francisco Gimeno wrote:

> El Jue 09 May 2002 18:06, Bob Phan escribió:
> > I think it would be a good idea for someone (I could do this if no one
> > wants to) to maintain a parsable list of all the use variables, what
> > they are for, and which ebuilds use them.  This would be useful for
> > writing tools that would want to know this information, or even for
> > automatic maintenence of a webpage for use variables.  CSV or XML
> > would be a good format for this.  XML may be overkill, expecially for
> > someone wanting to write a shell script with acess to this
> > information, but XML would also work great for c, perl, python, and
> > web maintenence.
> >
> > I have taken a look at /usr/portage/profiles/use.desc,
> > and while useful for users to read, it is not easily parsable.
> >
> > Any thoughts, suggestions?
> 
> and... going on work... we could make the same to the commands of the ebuild 
> packages, like dodir, doins, and those... to get them well-documented and in 
> an ordered way...

I don't follow?  The goal isn't to make an xml ebuild, as I rather
like them as shell scripts and it lowers the bar a little for people
that wan't to start writing their own.  The design goels for what I
suggested, is basically a way to keep track of all currently used USE
vars.  And basically, three things are important about each.

1) What they are called.
2) What they mean.
3) Which packages use them.

I think it would be a valuable resource to have a maintainable and
parsable list of these.  As it stands, I already have a perl script
that can dig out 1 & 2 and dump them into XML.  I'm going to tidy it
up a bit and probably post it to this group.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] Parsable list of all use variables.

[Francisco Gimeno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Jue 09 May 2002 18:06, Bob Phan escribió:
> I think it would be a good idea for someone (I could do this if no one
> wants to) to maintain a parsable list of all the use variables, what
> they are for, and which ebuilds use them.  This would be useful for
> writing tools that would want to know this information, or even for
> automatic maintenence of a webpage for use variables.  CSV or XML
> would be a good format for this.  XML may be overkill, expecially for
> someone wanting to write a shell script with acess to this
> information, but XML would also work great for c, perl, python, and
> web maintenence.
>
> I have taken a look at /usr/portage/profiles/use.desc,
> and while useful for users to read, it is not easily parsable.
>
> Any thoughts, suggestions?
Well... I think that with and xlstproc parser, XML could be HTML easily.
And maybe with XML you could write C programs... and so...

I beat for XML! 

Greetings!
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82tvDAE7Ivj6LuFMRAunBAJ9Y9l93gZGKLCLokzLfb1xxxwkOOACgqAmo
WP3SSbsX4q8XvTXEUVlu0L0=
=avUa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Parsable list of all use variables.

[Francisco Gimeno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Jue 09 May 2002 18:06, Bob Phan escribió:
> I think it would be a good idea for someone (I could do this if no one
> wants to) to maintain a parsable list of all the use variables, what
> they are for, and which ebuilds use them.  This would be useful for
> writing tools that would want to know this information, or even for
> automatic maintenence of a webpage for use variables.  CSV or XML
> would be a good format for this.  XML may be overkill, expecially for
> someone wanting to write a shell script with acess to this
> information, but XML would also work great for c, perl, python, and
> web maintenence.
>
> I have taken a look at /usr/portage/profiles/use.desc,
> and while useful for users to read, it is not easily parsable.
>
> Any thoughts, suggestions?

and... going on work... we could make the same to the commands of the ebuild 
packages, like dodir, doins, and those... to get them well-documented and in 
an ordered way...


Greetins
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82uEmAE7Ivj6LuFMRAvg6AKCbC3VCVRXC3CgM2r4edmb3lRBilQCdGiV3
EJHmb4b6nX2iEnnT7yOhMO0=
=ukrR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Parsable list of all use variables.

[Francisco Gimeno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi
> > well-documented and in an ordered way...
>
> I don't follow?  The goal isn't to make an xml ebuild, as I rather
> like them as shell scripts and it lowers the bar a little for people
> that wan't to start writing their own.  The design goels for what I
> suggested, is basically a way to keep track of all currently used USE
> vars.  And basically, three things are important about each.
>
> 1) What they are called.
> 2) What they mean.
> 3) Which packages use them.
>
> I think it would be a valuable resource to have a maintainable and
> parsable list of these.  As it stands, I already have a perl script
> that can dig out 1 & 2 and dump them into XML.  I'm going to tidy it
> up a bit and probably post it to this group.
ups... excuseme... I have reread the msg. and I'm with you either ;)
So... when do we begin ? 

Greets
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82ukvAE7Ivj6LuFMRAhjDAJ4vFn7uSLM6I7+D8RJhJBIdybKdhACgrzZK
6lcjS+yxMVyWlt/0I1Cyoww=
=lgk6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Parsable list of all use variables.

[George Shapovalov]

Isn't there one already?
/usr/portage/profiles/use.desc

The format cannot be simpler:
usevar - description
Is there any problem with parsing that? Even cut -d "-" would do it (not to 
mention awk and python).
This list is not enforced at present (that is if usevar is not listed there it 
will still be considered valid), but that can change at any moment.

As for the list of packages that use that var: that is going to be the largest 
problem. This tends to be very dynamic, also I would be hesitant to put that 
into use.desc as this will overload it (however technically this is very 
simple: just add one more delimeter and then list packages using this var 
(whitspace or comma separated))
There was a discussion on introducing IUSE into ebuilds which is supposed to 
list all use var that ebuild references. However there was not much activity 
on that. Also it is just possible to scan ebuild for "use XX" clauses and 
thus extract all referenced usevars.
I guess my point is that such back-reference list of packages referencing 
usevars can easily be dynamically reconstructed, and that I think is better 
solution than hand-maintained list.

George


On Thursday 09 May 2002 10:16, Bob Phan wrote:
> On Thu, 9 May 2002, Francisco Gimeno wrote:
> > and... going on work... we could make the same to the commands of the
> > ebuild packages, like dodir, doins, and those... to get them
> > well-documented and in an ordered way...
>
> I don't follow?  The goal isn't to make an xml ebuild, as I rather
> like them as shell scripts and it lowers the bar a little for people
> that wan't to start writing their own.  The design goels for what I
> suggested, is basically a way to keep track of all currently used USE
> vars.  And basically, three things are important about each.
>
> 1) What they are called.
> 2) What they mean.
> 3) Which packages use them.
>
> I think it would be a valuable resource to have a maintainable and
> parsable list of these.  As it stands, I already have a perl script
> that can dig out 1 & 2 and dump them into XML.  I'm going to tidy it
> up a bit and probably post it to this group.

Re: [gentoo-dev] Parsable list of all use variables.

[Karl Trygve Kalleberg]

On Thu, 9 May 2002, Bob Phan wrote:

> I have taken a look at /usr/portage/profiles/use.desc,
> and while useful for users to read, it is not easily parsable.

Actually it is. If you look at the lintool code, it parses the use.desc
file. What we do not get from this that we would get from XML is
validation.

We might consider starting using XML at a later stage, but then we'd have
to make a very easy-to-use XML API for bash first. Any takers ?

Karl T

Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

On Thu, 9 May 2002, George Shapovalov wrote:

> On Thursday 09 May 2002 10:16, Bob Phan wrote:
> > On Thu, 9 May 2002, Francisco Gimeno wrote:
> > > and... going on work... we could make the same to the commands of the
> > > ebuild packages, like dodir, doins, and those... to get them
> > > well-documented and in an ordered way...
> >
> > I don't follow?  The goal isn't to make an xml ebuild, as I rather
> > like them as shell scripts and it lowers the bar a little for people
> > that wan't to start writing their own.  The design goels for what I
> > suggested, is basically a way to keep track of all currently used USE
> > vars.  And basically, three things are important about each.
> >
> > 1) What they are called.
> > 2) What they mean.
> > 3) Which packages use them.
> >
> > I think it would be a valuable resource to have a maintainable and
> > parsable list of these.  As it stands, I already have a perl script
> > that can dig out 1 & 2 and dump them into XML.  I'm going to tidy it
> > up a bit and probably post it to this group.
> 

Please do not top-post. I moved it, and sorry about being picky.

> Isn't there one already?
> /usr/portage/profiles/use.desc
> The format cannot be simpler:
> usevar - description
> Is there any problem with parsing that? Even cut -d "-" would do it (not to 
> mention awk and python).
> This list is not enforced at present (that is if usevar is not listed there it 
> will still be considered valid), but that can change at any moment.

As I said, I've already looked at it.  And the format would be fine if
it was actually enforced.  Here are some outliars that I have found.

trusted

No dash, no description, not even a blank one.  Therefor, you cannot
tokenize based on dashes, since it is not gauranteed.  Then  you would
think, why not tokenize based on newlines?  Here's another one from
that file.

voodoo3 - Adds support for 3Dfx's Voodoo3 video chipset, else
          defaults to Voodoo4/5 support if not in USE

That eliminates being able to tokenize based on newlines.  Basically
use.desc is really only useful for users.  My suggestion would be to
either clean this file up to conform to some form of guideline, or to
make a mirror copy (ie _not_ to remove but to add in addition to) an
XML file with the same information.

> 
> As for the list of packages that use that var: that is going to be the largest 
> problem. This tends to be very dynamic, also I would be hesitant to put that 
> into use.desc as this will overload it (however technically this is very 
> simple: just add one more delimeter and then list packages using this var 
> (whitspace or comma separated))
> There was a discussion on introducing IUSE into ebuilds which is supposed to 
> list all use var that ebuild references. However there was not much activity 
> on that. Also it is just possible to scan ebuild for "use XX" clauses and 
> thus extract all referenced usevars.
> I guess my point is that such back-reference list of packages referencing 
> usevars can easily be dynamically reconstructed, and that I think is better 
> solution than hand-maintained list.

I've already written a script that can mine out all optional use
statements.  Adding the functionality to dynamically go backwards
through the dependancy tree would be trivial.

I just wanted to get a sense from all of you out there as to what you
would vote for as a better standard for keeping a separate list with
this information, which I or anyone can maintain.  It would be really
useful for a few scripts I've been meaning to write, such as a GTK+
based auto USE var generator.  And a "what options are available to me
in this ebuild before I install it" script.  I'm also sure others
would find some use for such information to be stored in a more usable
format.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

On Fri, 10 May 2002, George Shapovalov wrote:

> > it was actually enforced.  Here are some outliars that I have found.
> I've corrected these two (added description to trusted and got rid of \n for 
> voodoo3).
> 
Cool. That eliminates my problems with the original format.

> I would like to keep file format as simple as possible. It might be needed at 
> some point to have a very basic function implemented that would be desirable 
> in barebones system. It is not a good idea to have to include XML parsers 
> just because one file needs to be parsed (thats the same reason as the one 
> behind plain-text human readabla/easily parsable format for config files for 
> majority of the apps).
> I think it is just a matter of enforcing certain use.desc format. As it stands 
> now it can be parsed based on " - " key. I am going to raise this issue and 
> suggest another separator (dash is used quite frequently in package names and 
> some times in description). What do you think about "|"? Also ":" might be 
> more logical, but it can naturally occure in description.

I agree completely.  My original reasoning for XML was enforcing the
formatting and perhaps adding more information.  But for my purposes,
what is there should be good enough for now.  And actually, it doesn't
matter if there is a - in the description as long as there aren't any
in the use variables themselves.  You can split on - and request 2
tokens, which would put the second half, dashes and all, in the second
array item.

> > I've already written a script that can mine out all optional use
> > statements.  Adding the functionality to dynamically go backwards
> > through the dependancy tree would be trivial.
> Nice, could you submit this script to bugs.gentoo.org?

Yup, I'll tidy it up, add docs and an ebuild, and ship it off to
bugzilla tonight.

> > I just wanted to get a sense from all of you out there as to what you
> > would vote for as a better standard for keeping a separate list with
> > this information, which I or anyone can maintain.  It would be really
> I do not object the existence of such list. However I think it should not be 
> hand-maintained. Since you will have a script which will fish for referenced 
> use variables, better approach would be to have a tool that could generate 
> this back-reference file per request. My experience with duplicating 
> information is that things go insane if there is no defined authoritative 
> entity and in this case collection of ebuilds clearly should take precedence.
> BTW similar tool can be used to check validity of use.desc.

Good idea.  Currently, all the data it gathers _is_ from the ebuilds.
That way, the list of use vars it comes up with can be checked against
use.desc to make sure use.desc is not missing anything.  That should
be simple enough to add.  I had no intentions of hand maintaining
anything :).

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] ebuilds & suid question

[Grant Goodyear]

> what is the policy of gentoo for adding suid/guid bits in emerge scripts to 
> fix problems like this?

Um, we probably don't have a firm policy.  Generally we try to avoid
setting suid/guid bits unless absolutely necessary.

> Should i raise this as a bug for the samba emerge script??

Please do so.  At a minimum we should have the ebuild print out a note
that smbmnt should be set suid if users need to mount windows shares.

-g2boojum-

[gentoo-dev] ebuilds & suid question

[Alastair Nicol]

Hi,
  The samba ebuild doesnt make smbmnt suid root, this is only required
if a user wants to mount windows shares, rather than root.

my question is this...

what is the policy of gentoo for adding suid/guid bits in emerge scripts to 
fix problems like this?

Should i raise this as a bug for the samba emerge script??

thanks, Al

Re: [gentoo-dev] Parsable list of all use variables.

[George Shapovalov]

> As I said, I've already looked at it.  And the format would be fine if
Sorry, I did not notice that mentioned in original email.

> it was actually enforced.  Here are some outliars that I have found.
I've corrected these two (added description to trusted and got rid of \n for 
voodoo3).

> That eliminates being able to tokenize based on newlines.  Basically
> use.desc is really only useful for users.  My suggestion would be to
> either clean this file up to conform to some form of guideline, or to
> make a mirror copy (ie _not_ to remove but to add in addition to) an
> XML file with the same information.
I would like to keep file format as simple as possible. It might be needed at 
some point to have a very basic function implemented that would be desirable 
in barebones system. It is not a good idea to have to include XML parsers 
just because one file needs to be parsed (thats the same reason as the one 
behind plain-text human readabla/easily parsable format for config files for 
majority of the apps).
I think it is just a matter of enforcing certain use.desc format. As it stands 
now it can be parsed based on " - " key. I am going to raise this issue and 
suggest another separator (dash is used quite frequently in package names and 
some times in description). What do you think about "|"? Also ":" might be 
more logical, but it can naturally occure in description.


> I've already written a script that can mine out all optional use
> statements.  Adding the functionality to dynamically go backwards
> through the dependancy tree would be trivial.
Nice, could you submit this script to bugs.gentoo.org?


> I just wanted to get a sense from all of you out there as to what you
> would vote for as a better standard for keeping a separate list with
> this information, which I or anyone can maintain.  It would be really
I do not object the existence of such list. However I think it should not be 
hand-maintained. Since you will have a script which will fish for referenced 
use variables, better approach would be to have a tool that could generate 
this back-reference file per request. My experience with duplicating 
information is that things go insane if there is no defined authoritative 
entity and in this case collection of ebuilds clearly should take precedence.
BTW similar tool can be used to check validity of use.desc.

> useful for a few scripts I've been meaning to write, such as a GTK+
> based auto USE var generator.  And a "what options are available to me
> in this ebuild before I install it" script.  I'm also sure others
Neat, could you please create an appropriate bug on bugzilla, so things get 
registerd and your scripts will not get lost? I think at least some of them 
should make their way into gentoolkit.

George

Re: [gentoo-dev] Parsable list of all use variables.

[George Shapovalov]

On Friday 10 May 2002 09:50, Bob Phan wrote:
> I agree completely.  My original reasoning for XML was enforcing the
> formatting and perhaps adding more information.  But for my purposes,
> what is there should be good enough for now.  And actually, it doesn't
> matter if there is a - in the description as long as there aren't any
> in the use variables themselves.  You can split on - and request 2
There is even simplier solution to that: we can (and should) enforce space 
after usevar name. After all, these vars are garanteed to not have a 
whitespace in it ;). Also, it might become desirable to have a dash inside 
one of the use-vars, who knows?
This is the latest format proposal (basically the same as now, just an attempt 
to enforce it):
1. usevar definition is contained within a single line.
2. usevar is followed by space (?any whitespace?) then goes a single separator 
character (we can enforce "-", but parser may not care) then description 
field.



> > Nice, could you submit this script to bugs.gentoo.org?
>
> Yup, I'll tidy it up, add docs and an ebuild, and ship it off to
> bugzilla tonight.
Cool :).

George

Re: [gentoo-dev] Parsable list of all use variables.

[Karl Trygve Kalleberg]

On Fri, 10 May 2002, Bob Phan wrote:

> As I said, I've already looked at it.  And the format would be fine if
> it was actually enforced.  Here are some outliars that I have found.
> 
> trusted
> 
> No dash, no description, not even a blank one.  Therefor, you cannot
> tokenize based on dashes, since it is not gauranteed.  Then  you would
> think, why not tokenize based on newlines?  Here's another one from
> that file.
> 
> voodoo3 - Adds support for 3Dfx's Voodoo3 video chipset, else
>           defaults to Voodoo4/5 support if not in USE
> 
> That eliminates being able to tokenize based on newlines.  Basically
> use.desc is really only useful for users.  My suggestion would be to
> either clean this file up to conform to some form of guideline, or to
> make a mirror copy (ie _not_ to remove but to add in addition to) an
> XML file with the same information.

This regex handles those cases:

^([a-z0-9]+)[ \t]+-.*

> I've already written a script that can mine out all optional use
> statements.  Adding the functionality to dynamically go backwards
> through the dependancy tree would be trivial.
> 
> I just wanted to get a sense from all of you out there as to what you
> would vote for as a better standard for keeping a separate list with
> this information, which I or anyone can maintain.  It would be really
> useful for a few scripts I've been meaning to write, such as a GTK+
> based auto USE var generator.  And a "what options are available to me
> in this ebuild before I install it" script.  I'm also sure others
> would find some use for such information to be stored in a more usable
> format.

I used to think the format should be changed. If the use.desc file is
supposed to be only machine-readable, it certainly should be changed.

However, if users are supposed to read that file as well, we should not
change it, as it is currently easy enough to parse and extremely easy
to read.

There are currently 255 out of 2959 ebuilds that use undocumented use
flags. These use flags will have to be moved into use.desc.

There has been discussion of an IUSE var for each ebuild, that lists the
use flags that an ebuild can avail itself of. This would ease up the task
of collectiong these options. In the meantime, the regex 

[^#]*use ([a-z0-9]+).*

does the trick.


Karl T

Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

On Sun, 12 May 2002, Karl Trygve Kalleberg wrote:

> On Fri, 10 May 2002, Bob Phan wrote:
> 
<snip>
> > 
> > voodoo3 - Adds support for 3Dfx's Voodoo3 video chipset, else
> >           defaults to Voodoo4/5 support if not in USE
> > 
<snip>
> 
> This regex handles those cases:
> 
> ^([a-z0-9]+)[ \t]+-.*
> 
The problem with that regex is it only strips out the use variables.
I was doing something similar before.  But I wanted to be able to
easily parse out all the information in that file.

> > I've already written a script that can mine out all optional use
> > statements.  Adding the functionality to dynamically go backwards
> > through the dependancy tree would be trivial.
> > 
> > I just wanted to get a sense from all of you out there as to what you
> > would vote for as a better standard for keeping a separate list with
> > this information, which I or anyone can maintain.  It would be really
> > useful for a few scripts I've been meaning to write, such as a GTK+
> > based auto USE var generator.  And a "what options are available to me
> > in this ebuild before I install it" script.  I'm also sure others
> > would find some use for such information to be stored in a more usable
> > format.
> 
> I used to think the format should be changed. If the use.desc file is
> supposed to be only machine-readable, it certainly should be changed.
> 
> However, if users are supposed to read that file as well, we should not
> change it, as it is currently easy enough to parse and extremely easy
> to read.

I wouldn't suggest making it any harder to read.  Avoiding newlines
midrecord wouldn't make reading it much more difficult.  Especially if
empty lines were permitted.  And I liked Georges idea of splitting
each line into two parts, use-var<whitespace>description<newline>.
Where any whitespace minus newline would be permitted to split the use
var from the description.

> There are currently 255 out of 2959 ebuilds that use undocumented use
> flags. These use flags will have to be moved into use.desc.
> 
> There has been discussion of an IUSE var for each ebuild, that lists the
> use flags that an ebuild can avail itself of. This would ease up the task
> of collectiong these options. In the meantime, the regex 
> 
> [^#]*use ([a-z0-9]+).*
> 
> does the trick.

I was previously parsing that info out of the DEPEND and RDEPEND,
grabbing /\?\w+/ for the use vars, but your regex is more elegant.
I'll update my script to use that.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] Parsable list of all use variables.

[Bob Phan]

On Sun, 12 May 2002, Karl Trygve Kalleberg wrote:

<big snip>
> 
> There has been discussion of an IUSE var for each ebuild, that lists the
> use flags that an ebuild can avail itself of. This would ease up the task
> of collectiong these options. In the meantime, the regex 
> 
> [^#]*use ([a-z0-9]+).*
> 
> does the trick.
> 
I found while using this regex, some vars that were coming up were
quite suspect.  Those such as:
the
you
we
they

Maybe it's a perlism.  I just threw a

s/#.*$//

before using the regex to fix it.  And removed the [^#]*, which
wasn't working.  What did you use that regex in?  Just curious.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] Parsable list of all use variables.

[Karl Trygve Kalleberg]

On Mon, 13 May 2002, Bob Phan wrote:

>  What did you use that regex in?  Just curious.

Python's re regex module, which is descended from Perl.

Karl T

Re: [gentoo-dev] Parsable list of all use variables.

[George Shapovalov]

Hi Bob

short update on a situation.

On Monday 13 May 2002 06:31, Bob Phan wrote:
> > This regex handles those cases:
> >
> > ^([a-z0-9]+)[ \t]+-.*
> The problem with that regex is it only strips out the use variables.
This regexp is used by lintool at present to extract a list of use vars out of 
use.desc file. This in a sense enforses present format, however this is only 
one tool of which I know that actually parses use.desc at this point.
(and BTW, as it works, lintool will just ignore all run-over description 
lines, which is fine for the tool but is a bad idea if you want to get hold 
on descriptions as well. Thus I think single line per usevar entry should be 
enforced).

Also there were/are plans to assign values to usevars, for example:
arch = (ppc|sparc|x86)
gnome = 1.4

So far this was the only addition mentioned, so this will be possible to 
accomodate in a single human-readable file by slightly changing the format. 
Probably something of the form:
usevar = (list|of|values); description
can do.

However please understand that these are just that - plans, so old format 
(usevar - description\n) is now in force and I expect will be for some time.
As far as policy goes, the word was that there isn't real one. Basically it 
goes as far as it gets enforced by accepted tools, in this case lintool 
(which only checks for "usevar -" part anyway). If your script gets accepted 
it becames a new policy ;). However in order for it to be accepted it should 
peacefully coexist with lintool, therefore it would be a good idea to consult 
lintool code whenever you are uncertain about any USE-related formats).

George