[gentoo-portage-dev] Additional information to output: emerge -pv

[gentoo-portage-dev] Additional information to output: emerge -pv

[Dustin Spicuzza]

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

Hey,

I've been using Gentoo for a couple of years now... and portage was the 
#1 reason I kept using Gentoo over other Linux distros... and why I'm 
still using it.

Something that's always bugged me a lot is USE flags. Which, while I 
think that they are one of the best things about portage, I think that 
they are also one of the more annoying features as well... it can be 
relatively annoying to configure it all up. Especially researching what 
they are... yes, it just takes a little bit of effort to find them, but 
why not make it slightly easier?

Anyways, I made a patch (against Portage 2.0.51.22-r2, attached as 
verbose_use_patch.tar) that adds the description of each USE flag to the 
'emerge -pv <package>' command. The output for openoffice, for example, 
looks something like this...

[ebuild  N    ] app-office/openoffice-1.1.4-r1  -curl -hardened -java 
+kde -nptl +zlib 215,331 kB
  *  curl - Adds support for client-side URL transfer library
  *  hardened - activate default security enhancements for toolchain 
(gcc, glibc, binutils)
  *  java - Adds support for Java
  *  kde - Adds support for kde-base/kde (K Desktop Enviroment)
  *  nptl - Enable support for Native POSIX Threads Library, the new 
threading module (requires linux-2.6 or better usually)
  *  zlib - Adds support for zlib (de)compression

And, it does this for each package (only for verbose obviously) Its a 
very small, non-invasive patch, and quite small (a routine in 
portage_util.py, and 5 lines of code in emerge). 

I attached the patch here because I wasn't quite sure of the proper 
procedure for patch submission... anyways, thanks for all your work! 
Hopefully in the future I can contribute to this project.

Dustin Spicuzza

[-- Attachment #2: verbose_use_patch.tar --]
[-- Type: application/octet-stream, Size: 10240 bytes --]

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Simon Stelling]

Hi,

Dustin Spicuzza wrote:
> [ebuild  N    ] app-office/openoffice-1.1.4-r1  -curl -hardened -java 
> +kde -nptl +zlib 215,331 kB
>  *  curl - Adds support for client-side URL transfer library
>  *  hardened - activate default security enhancements for toolchain 
> (gcc, glibc, binutils)
>  *  java - Adds support for Java
>  *  kde - Adds support for kde-base/kde (K Desktop Enviroment)
>  *  nptl - Enable support for Native POSIX Threads Library, the new 
> threading module (requires linux-2.6 or better usually)
>  *  zlib - Adds support for zlib (de)compression
> 
> And, it does this for each package (only for verbose obviously) Its a 

Does it repeat the same use flags over and over again for each package, 
or just explain it once? Also, does it distinguish local from global use 
flags? I didn't have a look at the code, but keep in mind that local use 
flags may have different meanings although they're used for more than 
one package.
Also, i (personally) don't like this feature, but i use -v *always*, so 
I suggest you make it only print the explanation if -pvv is given.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Paul de Vrieze]

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

>
> I attached the patch here because I wasn't quite sure of the proper
> procedure for patch submission... anyways, thanks for all your work!
> Hopefully in the future I can contribute to this project.

The appropriate way would be to open a bug in bugzilla, assign it to the 
portage team and attach  the patch there (normally each file separately, 
not packed in a tarball)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Sandy McArthur]

How about making it so you need two -v switchs (eg: -vv) to get the
long listing? I use `emerge world -puv` all the time and don 't want
to have to scroll through so much stuff.

On 8/24/05, Dustin Spicuzza <dustin.spicuzza@wmich.edu> wrote:
> Hey,
> 
> I've been using Gentoo for a couple of years now... and portage was the
> #1 reason I kept using Gentoo over other Linux distros... and why I'm
> still using it.
> 
> Something that's always bugged me a lot is USE flags. Which, while I
> think that they are one of the best things about portage, I think that
> they are also one of the more annoying features as well... it can be
> relatively annoying to configure it all up. Especially researching what
> they are... yes, it just takes a little bit of effort to find them, but
> why not make it slightly easier?
> 
> Anyways, I made a patch (against Portage 2.0.51.22-r2, attached as
> verbose_use_patch.tar) that adds the description of each USE flag to the
> 'emerge -pv <package>' command. The output for openoffice, for example,
> looks something like this...
> 
> [ebuild  N    ] app-office/openoffice-1.1.4-r1  -curl -hardened -java
> +kde -nptl +zlib 215,331 kB
>   *  curl - Adds support for client-side URL transfer library
>   *  hardened - activate default security enhancements for toolchain
> (gcc, glibc, binutils)
>   *  java - Adds support for Java
>   *  kde - Adds support for kde-base/kde (K Desktop Enviroment)
>   *  nptl - Enable support for Native POSIX Threads Library, the new
> threading module (requires linux-2.6 or better usually)
>   *  zlib - Adds support for zlib (de)compression
> 
> And, it does this for each package (only for verbose obviously) Its a
> very small, non-invasive patch, and quite small (a routine in
> portage_util.py, and 5 lines of code in emerge).
> 
> I attached the patch here because I wasn't quite sure of the proper
> procedure for patch submission... anyways, thanks for all your work!
> Hopefully in the future I can contribute to this project.
> 
> Dustin Spicuzza
> 
> 
> 


-- 
Sandy McArthur

"Government big enough to supply everything you
need is big enough to take everything you have ...
The course of history shows that as a government
grows, liberty decreases." -- Thomas Jefferson

-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Brian Harring]

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

On Thu, Aug 25, 2005 at 10:15:26AM -0400, Sandy McArthur wrote:
> How about making it so you need two -v switchs (eg: -vv) to get the
> long listing? I use `emerge world -puv` all the time and don 't want
> to have to scroll through so much stuff.
Conflicts with -vv usage in >=2.1 which pulls from metadata, dumping 
maintainer/herd.

Or just extends it...
/me shrugs, eenie meenie on that one
~harring


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

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Brian Harring]

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

On Thu, Aug 25, 2005 at 11:14:50AM -0500, Brian Harring wrote:
> On Thu, Aug 25, 2005 at 10:15:26AM -0400, Sandy McArthur wrote:
> > How about making it so you need two -v switchs (eg: -vv) to get the
> > long listing? I use `emerge world -puv` all the time and don 't want
> > to have to scroll through so much stuff.
> Conflicts with -vv usage in >=2.1 which pulls from metadata, dumping 
> maintainer/herd.
> 
> Or just extends it...
> /me shrugs, eenie meenie on that one

Correction, I'm wrong- that's emerge -sv I'm thinking about.

~harring

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

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Dustin Spicuzza]

 > The appropriate way would be to open a bug in bugzilla, assign it to 
the portage team
 > and attach the patch there (normally each file separately, not packed 
in a tarball)

Thanks. Will do.

 > How about making it so you need two -v switchs (eg: -vv) to get the 
long listing? I use
 > `emerge world -puv` all the time and don 't want to have to scroll 
through so much stuff.

Good idea... it shouldn't be a big deal to do that... I was just trying 
to keep the patch nice and simple.

 > Does it repeat the same use flags over and over again for each 
package, or just explain
 > it once? Also, does it distinguish local from global use flags?

It repeats the USE flags for each package, but ONLY the use flags that 
apply to that package. Personally, I think this is a more desirable 
behavior, because of when you do something like 'emerge world', then 
you'll have this really BIG list of stuff, and lots of repeating USE 
flags. However, it puts a empty line between each package, so that each 
list of USE flags is shown nicely for each package.. like this:

[stuff here] package useflag useflag2
* useflag - does something
* useflag2 - does something else

[stuff here] package useflag3 useflag
* useflag3 - does yet another thing
* useflag - does something

And so on... for the entire list. Currently, it searches global flags 
first, then falls back to local flags... but you're right -- its a 
better idea to search locals first, then globals. I don't really think 
its necessary though to note that its a local flag or a global flag... 
its not like it matters too much when you're trying to decide whether 
you want to set it or not. You just want to know what the package wants 
to use it for. I spose it could do something like * [local] useflag - 
description, and * [global] useflag - description...

Dustin
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Dustin Spicuzza]

>
>Actually, I'd find it useful personally.
>People add *weird* use flags sometimes.
>  
>
LoL... yes, thats true.

A suggestion possibly to keep in mind is what if all functionality 
related to USE flags were somehow implemented in a seperate class/set of 
functions... or maybe that's already being done. But I mean, the job of 
determining which flags apply to what package and managing all that and 
how it works... I noticed that (at least in stable) a lot of it is in 
portage.config, but maybe it could be a seperate class that 
portage.config uses.. and other things (like deps, etc). Then stuff like 
outputting USE flags, or adding additional ways to determine which USE 
flags to actually use for each package, would all be in one location, 
lending itself to code reuse...

Of course, this is just from my looking at portage stable for a week or 
so... maybe its already being done. :)

Dustin
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Thomas de Grenier de Latour]

On Thu, 25 Aug 2005 13:54:20 -0400
Dustin Spicuzza <dustin.spicuzza@wmich.edu> wrote:

>  > The appropriate way would be to open a bug in bugzilla, assign
>  > it to the portage team and attach the patch there (normally
>  > each file separately, not packed in a tarball)
> 
> Thanks. Will do.

May be a duplicate of bug #84884 though, which has, among other
things, a patch for emerge (2.0.51.x too) similar in purpose to
what you are proposing (although there are some cosmetic
differences, like option name or the info being summarized at the
end instead of being displayed per package):
https://bugs.gentoo.org/show_bug.cgi?id=84884

Btw, there was not much feedback on that one... would someone be
interested if i port it to CVS HEAD? As far as i remember, it
should be pretty easy, although the emerge patch has to be
rewritten.

-- 
TGL.
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Alec Warner]

Dustin Spicuzza wrote:

> Hey,
>
> I've been using Gentoo for a couple of years now... and portage was 
> the #1 reason I kept using Gentoo over other Linux distros... and why 
> I'm still using it.
>
> Something that's always bugged me a lot is USE flags. Which, while I 
> think that they are one of the best things about portage, I think that 
> they are also one of the more annoying features as well... it can be 
> relatively annoying to configure it all up. Especially researching 
> what they are... yes, it just takes a little bit of effort to find 
> them, but why not make it slightly easier?
>
> Anyways, I made a patch (against Portage 2.0.51.22-r2, attached as 
> verbose_use_patch.tar) that adds the description of each USE flag to 
> the 'emerge -pv <package>' command. The output for openoffice, for 
> example, looks something like this...
>
> [ebuild  N    ] app-office/openoffice-1.1.4-r1  -curl -hardened -java 
> +kde -nptl +zlib 215,331 kB
>  *  curl - Adds support for client-side URL transfer library
>  *  hardened - activate default security enhancements for toolchain 
> (gcc, glibc, binutils)
>  *  java - Adds support for Java
>  *  kde - Adds support for kde-base/kde (K Desktop Enviroment)
>  *  nptl - Enable support for Native POSIX Threads Library, the new 
> threading module (requires linux-2.6 or better usually)
>  *  zlib - Adds support for zlib (de)compression
>
> And, it does this for each package (only for verbose obviously) Its a 
> very small, non-invasive patch, and quite small (a routine in 
> portage_util.py, and 5 lines of code in emerge).
> I attached the patch here because I wasn't quite sure of the proper 
> procedure for patch submission... anyways, thanks for all your work! 
> Hopefully in the future I can contribute to this project.
>
> Dustin Spicuzza

I like it but I'd like to see it in another tool.  Or in the case of 
HEAD, an emerge module.  I know it's a PITA right now because all the 
dependencies are depgraph related and it hasn't been easy to rip it 
out.  It would be nice to have a set of modules for generating metadata 
like this in script form for servers as opposed to some kind of weird 
emerge output that then needs some regex voodoo process.

Just my two cents :)
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Additional information to output: emerge -pv

[Brian Harring]

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

On Thu, Aug 25, 2005 at 06:15:36PM +0000, Dustin Spicuzza wrote:
> 
> >
> >Actually, I'd find it useful personally.
> >People add *weird* use flags sometimes.
> > 
> >
> LoL... yes, thats true.
> 
> A suggestion possibly to keep in mind is what if all functionality 
> related to USE flags were somehow implemented in a seperate class/set of 
> functions... or maybe that's already being done. But I mean, the job of 
> determining which flags apply to what package and managing all that and 
> how it works... I noticed that (at least in stable) a lot of it is in 
> portage.config, but maybe it could be a seperate class that 
> portage.config uses.. and other things (like deps, etc). Then stuff like 
> outputting USE flags, or adding additional ways to determine which USE 
> flags to actually use for each package, would all be in one location, 
> lending itself to code reuse...
> 
> Of course, this is just from my looking at portage stable for a week or 
> so... maybe its already being done. :)
It's being done :)
Essentially, you have this
config
domain
|--repo(s)
|  |--cache(s)
|  |--sync
|--vdb(s)
|--profile(s)

Domain is generated from configuration, as are all of the other 
objects; the config class just holds config data, and instantiates 
objects, shuffling them around dependant on an external file that 
states the rules for the config (in the process, stating how to 
instantiate the objs).

Config build data is domain data; your normal ebuild repository is an 
'unconfigured' repository, iow, you can toggle stuff on it to change 
the metadata of packages it returns.
The domain during instantiation notes that it has an unconfigured repo 
in it's list, inspects the repo instance for what is needed to 
configure it (and the func to call), calls the func with the 
configurables supplied, and uses the returned repo instead of the 
unconfigured repo.

Via this, the config data (USE, build, etc) is pushed down into the 
repo.  The configured repo wraps the unconfigured repo's returned 
packages with it's own wrapper that binds the config data into it, and 
hands that back.

Probably not a great description, but the short version is it works 
pretty well, and is pretty well encapsulated.

What I'd *like* to see is the use.{local.,}desc information bound into 
the repository, and have it supplied from the repository object; doing 
so keeps that data in the repo backend, not screwing up any 
abstractions that are carefully defined to allow for remote 
replacements.

Haven't proposed it to -dev yet, but I'd like to see package.* and 
use.* moved out of profiles/ , and into it's own base directory in the 
ebuild repository.
Reasoning is that profile objs are seperate from repo objs; the fs 
layout should reflect that to some degree.  It's cleaner anyways, imo. 
:)
~harring

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