From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bob@endlessrecursion.net>
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org
X-Spam-Level:
X-Spam-Status: No, score=0.9 required=5.0 tests=DATE_IN_PAST_03_06,
DKIM_ADSP_NXDOMAIN,DMARC_MISSING,MAILING_LIST_MULTI autolearn=no
autolearn_force=no version=4.0.0
Received: from lucifer.evil-core.com (evil-core.com [63.160.181.167])
by chiba.3jane.net (Postfix) with ESMTP id 61803AC595
for <gentoo-dev@gentoo.org>; Fri, 10 May 2002 08:49:34 -0500 (CDT)
Received: from localhost (bob@localhost)
by lucifer.evil-core.com (8.10.2/8.10.2) with ESMTP id g4A9lXV17129
for <gentoo-dev@gentoo.org>; Fri, 10 May 2002 09:47:33 GMT
Date: Fri, 10 May 2002 09:47:33 +0000 (/etc/localtime)
From: Bob Phan <bob@endlessrecursion.net>
X-Sender: bob@lucifer.evil-core.com
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Parsable list of all use variables.
In-Reply-To: <200205091513.08657.georges@its.caltech.edu>
Message-ID: <Pine.LNX.4.21.0205100937270.17076-100000@lucifer.evil-core.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: gentoo-dev-admin@gentoo.org
Errors-To: gentoo-dev-admin@gentoo.org
X-BeenThere: gentoo-dev@gentoo.org
X-Mailman-Version: 2.0.6
Precedence: bulk
Reply-To: gentoo-dev@gentoo.org
List-Help: <mailto:gentoo-dev-request@gentoo.org?subject=help>
List-Post: <mailto:gentoo-dev@gentoo.org>
List-Subscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
<mailto:gentoo-dev-request@gentoo.org?subject=subscribe>
List-Id: Gentoo Linux developer list <gentoo-dev.gentoo.org>
List-Unsubscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>,
<mailto:gentoo-dev-request@gentoo.org?subject=unsubscribe>
List-Archive: <http://lists.gentoo.org/pipermail/gentoo-dev/>
X-Archives-Salt: 346136b3-a6d3-48ed-acc1-0c93462a8555
X-Archives-Hash: 4c50d6397c57f16be6de18252deef8eb
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.
*/