Bugzilla Bug 6411

Maybe it would be handy for some people that they could make their own 
favourites files like the world file. E.g. one could make files such as 
critical, non-critical, graphics, servers, ...

Perhaps Gentoo should give more standard favourite files, and let some 
packages automatically insert themselves in such files (perhaps most important 
for this is "servers"). The world file could then be used to include really 
ALL installed packages, and a new one to act as it does now.

This is absolutely not critical or highly needed, just a little thougt. The 
different favourites files should not be that difficult to code i imagine (i 
could be wrong, i have never looked at the portage internals, since i wouldn't 
understand a thing of it)

Just a thought for the far away future.

I just wanted to request this feature and found this entry.
So indeed this would be a tremendously useful feature.Having a dir where you can
put your files having a simple format (package name per line??)

then you could emerge -u -p --category mydevel
and it would say you need distcc, cvs, valgrind and gdb upgraded.
The most upsetting thing now is having to grep the huge list of world updates if
I only want some specific tool and don't care about all the others.

I also like the idea of user defined package-sets.

*** Bug 89052 has been marked as a duplicate of this bug. ***

See GLEP 21

http://www.gentoo.org/proj/en/glep/glep-0021.html

Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 

*** Bug 100649 has been marked as a duplicate of this bug. ***

patch

Created an attachment (id=94659) [details]
against svn

no unmerging yet.

That patch is incomplete, or where is portage_sets.py?
Also don't really like the existing part of it, sets shouldn't require a
special option and system/world should IMO be implemented as sets right from
the start.

(In reply to comment #9)
> That patch is incomplete, or where is portage_sets.py?
> Also don't really like the existing part of it, sets shouldn't require a
> special option and system/world should IMO be implemented as sets right from
> the start.
> 

Ahh yes it was very early :P  I will post a new one soon with portage_sets.py
soon ;)

Sets requiring a special option is necessary imho, otherwise you incure an
annoying amount of processing to figure out that items in myfiles are actually
a set; you need to do this to set the proper options in depgraph.  Also mixing
sets and normal packages is bad idea (for similar depgraph related reasons).

System and world are already sets, although I plan to unify SetCreate and
xCreate, mostly I was trying not to break the existing functionality with this
first try.

Created an attachment (id=96849) [details]
Patch against svn, round two

Ok, this should be a bit better (and complete).  Out of the box it should
support ["world","system","all"] sets as well as anything you place in
/etc/portage/sets/

emerge <setname1> <setname2> should work fine

There is one place where it bitches about unavailable atoms; I need to fix that
still.

Created an attachment (id=96851) [details]
Fix a bug in the System set, also squelch some complaining about missing atoms
in porttree by checking for them in the vdb.

Ok apparently you people want backend support (via dbapi); I'll cut myself and
then get to work on a patch.

*** Bug 154753 has been marked as a duplicate of this bug. ***

(In reply to comment #14)
> *** Bug 154753 has been marked as a duplicate of this bug. ***
> 

Just to add; when I made 154753 (without noticing this bug); one of the
suggestions was to have basic set operations; so that you could do something
like world \minus system, and things like that.  Also, it would be convenient
to type out sets from their elements on the command line; like world \minus
{openoffice}.  

Just some thoughts...
-wes

*** Bug 158215 has been marked as a duplicate of this bug. ***

(In reply to comment #16)
> *** Bug 158215 has been marked as a duplicate of this bug. ***
> 

That was me.  I searched!  Honest.

Anyway, as it says, there needs to be a "toolchain" argument that gets used
when updating the compiler, otherwise when you use "system" you get to build
300 things, 90% of which are not toolchain.  Then you rebuild them all when you
do a "emerge -eav world".

I think this should be a standard item.

it's easy enough to just do `emerge -av glibc binutils gcc`, but i guess it
might be useful if it's easy enough to do.  do any of the alt arches have
different toolchains?

*** Bug 204493 has been marked as a duplicate of this bug. ***

*** Bug 206528 has been marked as a duplicate of this bug. ***

This is implemented in portage-2.2 (lacks a bit on the documentation front
though).