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
> $>>cat /etc/portage/sets/jed.dev
> 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: