[gentoo-user] flag details

[gentoo-user] flag details

[James]

Hello,


So, I use euse to read aobut flags. Sometimes the same flag has slightly,
but significantly different meanings depending on the packages it
is use on. A tool with perhaps more detail or that parse the ebuild/sources
for even greater detail information?

I also use Ciaran's old (filter)script on flags:

explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
portdir)/profiles/use.{,local.}desc; }

Which is due for updating. If does a nice job of filtering out the
package version details, which I do not need most of the time.

Suggested fixes to Ciarans old filter quickie I use from by bashrc?

Are there any more detailed tools, even gui based tools, for 
reading about the details of what a flag does on a given package
or information related to compile-time or run-time settings on a
given code (but not including looking at the sources, I know I can 
do that)?

(Gmane on gentoo user is working again from a browser window (yea).
Sorry for the recent noisy_posts.


curiously,
James

Re: [gentoo-user] flag details

[Jc García]

2014-11-24 11:09 GMT-06:00 James <wireless@tampabay.rr.com>:
> Hello,
>
>
> So, I use euse to read aobut flags. Sometimes the same flag has slightly,
> but significantly different meanings depending on the packages it
> is use on. A tool with perhaps more detail or that parse the ebuild/sources
> for even greater detail information?
>
> I also use Ciaran's old (filter)script on flags:
>
> explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
> portdir)/profiles/use.{,local.}desc; }
>
> Which is due for updating. If does a nice job of filtering out the
> package version details, which I do not need most of the time.
>
> Suggested fixes to Ciarans old filter quickie I use from by bashrc?
>
> Are there any more detailed tools, even gui based tools, for
> reading about the details of what a flag does on a given package
> or information related to compile-time or run-time settings on a
> given code (but not including looking at the sources, I know I can
> do that)?
>
> (Gmane on gentoo user is working again from a browser window (yea).
> Sorry for the recent noisy_posts.
>
>
I use
$ equery u cat/pkg
It list the useflags and what the metadata.xml of the package says
about each of them, plus highlights the active ones if you have the
package already merged.


> curiously,
> James
>
>

[gentoo-user] Re: flag details

[James]

Jc García <jyo.garcia <at> gmail.com> writes:


> I use
> $ equery u cat/pkg
> It list the useflags and what the metadata.xml of the package says
> about each of them, plus highlights the active ones if you have the
> package already merged.

yea that helps. But the information is a terse, single phrase usually.
I'm looking for something (if it exists) that is more detailed
about the flag usage and issues. Maybe nothing exists? Maybe
it's only avaiable reading the sources?



James 

Re: [gentoo-user] Re: flag details

[Michael Orlitzky]

On 11/24/2014 01:19 PM, James wrote:
> Jc García <jyo.garcia <at> gmail.com> writes:
> 
> 
>> I use
>> $ equery u cat/pkg
>> It list the useflags and what the metadata.xml of the package says
>> about each of them, plus highlights the active ones if you have the
>> package already merged.
> 
> yea that helps. But the information is a terse, single phrase usually.
> I'm looking for something (if it exists) that is more detailed
> about the flag usage and issues. Maybe nothing exists? Maybe
> it's only avaiable reading the sources?
> 

Basically. It kinda sucks. To fix it, we'd need a policy that every
ebuild has to properly document each of its USE flags in metadata.xml,
which means explaining how it actually affects the package, and not just
"enables libfoo." Then we'd need a repoman check to bitch at people who
don't do it.

Personally I'd be strongly for such a policy, even if it means every
package in the tree would become "in violation" overnight. This is
something that users could easily help with, by posting updated
metadata.xml on b.g.o.

Re: [gentoo-user] Re: flag details

[Emanuele Rusconi]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

When in doubt I just read the ebuild and try to understand what's going on.

A policy would be nice, though, and sometimes even reading the ebuild
leaves me guessing.
As you point out, saying "foo: enables libfoo" leaves me wandering "OK, but
what the f* would I need foo for??"

-- Emanuele Rusconi

On 24 November 2014 at 19:29, Michael Orlitzky <mjo@gentoo.org> wrote:

> On 11/24/2014 01:19 PM, James wrote:
> > Jc García <jyo.garcia <at> gmail.com> writes:
> >
> >
> >> I use
> >> $ equery u cat/pkg
> >> It list the useflags and what the metadata.xml of the package says
> >> about each of them, plus highlights the active ones if you have the
> >> package already merged.
> >
> > yea that helps. But the information is a terse, single phrase usually.
> > I'm looking for something (if it exists) that is more detailed
> > about the flag usage and issues. Maybe nothing exists? Maybe
> > it's only avaiable reading the sources?
> >
>
> Basically. It kinda sucks. To fix it, we'd need a policy that every
> ebuild has to properly document each of its USE flags in metadata.xml,
> which means explaining how it actually affects the package, and not just
> "enables libfoo." Then we'd need a repoman check to bitch at people who
> don't do it.
>
> Personally I'd be strongly for such a policy, even if it means every
> package in the tree would become "in violation" overnight. This is
> something that users could easily help with, by posting updated
> metadata.xml on b.g.o.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2206 bytes --]

[gentoo-user] Re: flag details

[James]

Emanuele Rusconi <emarsk <at> gmail.com> writes:


> When in doubt I just read the ebuild and try to understand what's 
> going on.  A policy would be nice, though, and sometimes even reading 
> the ebuild leaves me guessing.  As you point out, saying "foo: enables   
> libfoo" leaves me wandering "OK, but what the f* would I need foo for??"


I wonder if there is a reasonable why to extend app-portage/elogviewer

to parse more more details related to flags, or at leaset compile-time and
run-time details?


curiously,
James

Re: [gentoo-user] flag details

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Mon, Nov 24, 2014 at 05:09:36PM +0000, James wrote:

> So, I use euse to read aobut flags. Sometimes the same flag has slightly,
> but significantly different meanings depending on the packages it
> is use on. A tool with perhaps more detail or that parse the ebuild/sources
> for even greater detail information?

I was out of country so couldn't read mail the last few days.

My answer to your question: ufed
This program seems very little known around the list. It doesn't give you
more detail than euse, but it shows you what is available in an easy to
view (and edit!) list.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

I never err!  Once I thought I was in error, but I was mistaken.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-user] Re: flag details

[James]

Frank Steinmetzger <Warp_7 <at> gmx.de> writes:


> > A tool with perhaps more detail or that parse the ebuild/sources
> > for even greater detail information?

> I was out of country so couldn't read mail the last few days.

> My answer to your question: ufed
> This program seems very little known around the list. It doesn't give you
> more detail than euse, but it shows you what is available in an easy to
> view (and edit!) list.

Very cool! Nice format.

Like I wrote previously, a greater granularity of information too. Maybe
something that parses out runtime and compile time information related
to the flag settings, even if it only works after a given package
is installed.

Maybe a preprocessor (parser) that diffs the code that is to be 
compiled, with and without a given flag selected? Or at leaast
references additional code.

Other ideas for the basis of an advance mechanism is of interest to me.


thx,
James