On 06/16/2012 02:56 PM, Duncan wrote:
> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.  
> Since I've been working with kde4 since it was overlay-only and sets-
> only, no meta-packages, I've been using sets for quite awhile and it's 
> now entirely integrated into how I work with portage.
> 
> When I setup my netbook on gentoo, I wanted most of the same setup as on 
> my main machine, but with some differences, so I had to go thru the main 
> machine's world file and pick and choose what I needed.
> 
> What I quickly realized is that my kde packages were already nicely 
> categorized into sets, so all I really needed to do was split up the rest 
> of the world file into a bunch of other sets, by category.  So for 
> instance:
> 
> $>>cat /etc/portage/sets/jed.dev
> dev-util/ccache
> dev-util/desktop-file-utils
> dev-vcs/git
> sys-devel/bin86
> sys-devel/gcc
> sys-devel/gdb
> 
> 
> I have 24 such sets including my (customized) kde sets.  All packages 
> formerly listed in the world file are found in these sets, instead, and 
> of course the sets are in turn listed in /var/lib/portage/world_sets.
> 
> My world file is normally entirely empty, tho I do use it occasionally 
> for packages I haven't decided whether I want to keep or not, but want to 
> protect from --depclean, which I run after each update.  So my world file 
> serves as a kind of package purgatory, until I decide whether it's going 
> to be a part of my normal system, or removed.
> 
> The sets, meanwhile, break the former world file down into much more 
> manageable categorized chunks, each of which is short enough and 
> categorized specifically enough that if a package is no longer needed, it 
> immediately sticks out like a sore thumb, as it's not lost among the 
> noise of hundreds of "twisty packages, all different". =:^)
> 
> 
> While not a direct solution to the problem at hand, proper use of sets 
> WILL and DOES dramatically ease gentoo world-package administration, 
> going a long way toward eliminating crufty world lists simply by allowing 
> them to be cut into nice little chunks that can be categorized in ways 
> that make sense for an individual site, so the cruft sticks out like the 
> sore thumb it can really be, and is thus easily found and removed.
> 
> 
> Meanwhile, another bonus of sets is the extra protection it gives you if 
> you try to emerge -C something in a sets file (as opposed to the world 
> file itself). =:^)  Seeing that warning that the package is in a set and 
> can't be directly unmerged is rather like seeing the warning that it's in 
> @system, except that user sets are easier to directly manage, and it has 
> saved my butt a couple times when I was really too sleepy to be adminning 
> the system in the first place.  But it's easy enough to remove (or 
> comment) that line from the set, if removal is really intended, and 
> that's what would ultimately need to be done anyway, to prevent it 
> getting remerged.
> 
> 
> Unfortunately, it has begun to look like sets are where baselayout2 and 
> openrc were for many years, "forever coming, never getting here", at 
> least for stable or even unmasked into ~arch. =:^(

Support for /etc/portage/sets is included in portage-2.1.11:

  https://bugs.gentoo.org/show_bug.cgi?id=384061
-- 
Thanks,
Zac