[gentoo-user] Re: flag details
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
[gentoo-user] Re: flag details
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
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
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 m...@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.
[gentoo-user] Re: flag details
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
