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 attachment 94659 [details, diff] 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 attachment 96849 [details, diff] 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 attachment 96851 [details, diff] 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).
