A few quick gentoo tips before we get to the instructional material.
- Emerge world as often as you can. Once a week is probably a good frequency.
- Unless you’ve got a rock solid track record emerging world, don’t do it when you are really tired.
- In the best interest of the above, and your sanity, minimize the number of tilde keywords you have unmasked. I got all adventurous with one of my servers some years ago and there’s no good exit strategy. Sometimes it’s a pride point, other times, just pain.
- Don’t unmerge zlib. Just don’t, even if you are planning to put it right back. Pretty much nothing can run without it. Not portage, and not make, so you can’t get it back really. If you did, just copy libz.so (and symlinks) from another machine (probably of the same architecture).
- Also, don’t run eclean. It will break a lot of ebuilds and can’t even do that particularly well.
Getting setsy with portage
One of the main disadvantages of portage is the generally poor grouping of related packages. There are:
- Package Categories (media-libs, dev-python, etc.) – These are pretty great, except when a package’s category changes and some ebuilds don’t pick up on that change. There is some way for portage people to redirect old ebuilds to new packages, but it has failed me more than once. Also, package categories don’t speak much to dependencies (not that they should). Portage/ebuild people decide on these, though the project maintainers might have some say.
- Meta Packages (kde-meta) – Not many of these, but they seem to mostly be a dependency container. They are fine for installing, if a bit opaque, but they can be terrible for uninstalling. I’ve uninstalled old metas that left their obsolete and orphaned packages strewn about (kde 4.2 stuff). These are made by the project maintainers, I think.
- “Profiles”(world, system) – Not a great name (maybe the wrong name?), but these aren’t as helpful and commonly used as they should be. Emerging world is definitely useful, but there could be a more granular operation between individual packages and ALL PACKAGES. These are generally automatically constructed for the user, though the user can do some manual editing.
Oh KDE, you slay me.
Enter sets
Sets are basically like profiles, but the user gets a lot more control. They are groups of packages that can be reference like:
emerge --ask --update @my-set
You’ve got to admit that’s nicer than doing something like this.
Now when I said “Enter sets,” I meant… almost. Sets are only available in portage 2.2+. So the first step is to get that. Before that, I want to mention that it is technically still in alpha and a broken portage can make it hard to revert to a working portage. Nevertheless, so far it works fine for me and a lot of others have been using it since early 2009. In /etc/portage/package.unmask, add:
>=sys-apps/portage-2.2.0_alpha8
And in /etc/portage/package.keywords add:
sys-apps/portage ~*
Now, just emerge --ask portage and make sure it’s gonna pull in 2.2.
Your first set
Long story short, the format of the most basic user sets is just like the world file under /var/lib/portage/world. Just make a file with a list of packages, one per line, and put that file under /etc/portage/sets. For example, a set of scripting languages:
dev-lang/nodejs
dev-lang/php
=dev-lang/python-3.1.3
>=dev-lang/ruby-1.8.7_p249-r2
dev-lang/tcl
Now you can refer to that list of package like:
emerge --ask --update --deep @my-scripting-set
It may be prudent to prefix your sets so they don’t conflict with any other packages.
How to really clean up your system
By now you’ve probably seen the light, but I’m going to share one of my favorite uses so far to drive the point home. Say you’ve let your system go for a while, and you’ve accumulated some packages. Maybe you’ve switched from Gnome to KDE or maybe all the way to xmonad; regardless there is cruft to be removed. Here’s how you clean that stuff the Right Way:
- Update your gentoolkit and portage
- equery for some packages to remove and save the list:
equery list kde-*/* > ~/kde_installed_packages_12122010 - Review the result and format properly. equery gives specific versions by defaults, so we’re just gonna throw ‘=’ in front of every line to make them valid package atoms. We’ll use sed:
sed ':a;N;$!ba;s/\n/\n=/g' ~/my-kde-setYou’ll have to manually add one more equal sign for the first line, but that should work.
- Review the result and move the file into place:
mv ~/my-kde-set /etc/portage/sets/ - Depclean and unmerge:
emerge --depclean --ask --verbose @my-kde-set
Ah, so fresh and so clean. You should move the set file out of the /etc/portage/sets directory now.
Conclusion
Sets fill a much-lamented (by me) gap in portage. They add organizational power without removing fine-grained control, without which Gentoo would not be Gentoo. My only concern is
Why did this take so long? Given that this is basically how ‘world’ has always worked and we’re well into version 2, we should have had this ages ago. Also, sets are really not that complex or tailored to package management, I wonder if archlinux or some other distro has solved this better. Of course, I’ve only scratched the surface, and there’s a lot more you can do with sets, it seems. For a good starting point, you can do a search on sets.conf.
P.S. The screenshot above was brought to you by ImageMagick:
import -window root ~/screenshot.png
Superdrivel 