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
