It's often said, that Gentoo is all about choice, but that doesn't quite fit what it is for me.
The highest ability to choose is Linux from scratch, after all, and I can have any amount of choice in every distribution by just going deep enough (and investing enough time).
What really distinguishes Gentoo for me is that it makes it convenient to choose.
Since we all have a limited time budget, that means, many of us only have real freedom to choose, because we use Gentoo which makes it possible to choose, but that doesn't ring true in general - it misses the reason, why we can choose.
So what Gentoo gives me is not just choice, but convenient choice.
Some examples to illustrate the point:
I recently rebuilt my system after deciding to switch my disk layout (away from reiserfs towards a simple ext3 with reiser4 for the portage tree). When doing so I decided to try to use a "pure" KDE 4 - that means, a KDE 4 without any remains from KDE3 or qt3.
To use kde without any qt3 applications, I just had to put "-qt3" and "-qt3support" into my useflags in /etc/make.conf and "emerge -uDN world" (and solve any arising conflicts).
Imagine doing the same with a (K)Ubuntu...
Similarly to enable emacs support on my GentooXO (for all programs which can have emacs support), I just had to add the "emacs" useflag and "emerge -uDN world".
Just add
ACCEPT_LICENSE="-* @FSF-APPROVED @FSF-APPROVED-OTHER"
to your /etc/make.conf to make sure you only get software under licenses which are approved by the FSF.
For only free licenses (regardless of the approved state) you can use:
ACCEPT_LICENSE="-* @FREE"
All others get marked as masked by license. Default (no ACCEPT_LICENSE in /etc/make.conf) is “* -@EULA”: No unfree software. You can check your setting via emerge --info | grep ACCEPT_LICENSE. More information…
Another part where choosing is made convenient in Gentoo are testing and unstable programs.
I remember my pain with a Kubuntu, where I wanted to use the most recent version of Amarok. I either had to add a dedicated Amarok-only testing repository (which I'd need for every single testing program), or I had to switch my whole system into testing. I did the latter and my graphical package manager ceased to work. Just imagine how quickly I ran back to Gentoo.
And then have a look at the ease of deciding to take one package into testing in Gentoo:
Now I must admit, that it isn't yet perfectly convenient. What I'd really need is a tool to say something like
The first to add testing versions of all required but missing packages into my package keywords, and the second to add useflags for all packages which need a certain useflag to support the package I want to emerge.
But even without that it's very convenient as long as the testing package doesn't have long list of requirements which are also testing.
And for some special parts (like KDE 4) I can easily say something like
(I don't have the kde-testing overlay on my GentooXO, where I write this post, so the exact command might vary slightly)
So to finish this post: For me, Gentoo is not only about choice. It is about convenient choice.
And that means: It gives the power to choose to everybody.
I hope you enjoy it as I do!
To keep my Gentoo up to date, I use daily and weekly update scripts which also always run revdep-rebuild after the saturday night update :)
My daily update is via pkgcore to pull in all important security updates:
pmerge @glsa
That pulls in the Gentoo Linux Security Advisories - important updates with mostly short compile time. (You need pkgcore for that: "emerge pkgcore")
Also I use two cron scripts.
Note: It might be useful to add the lafilefixer to these scripts (source).
The following is my daily update (in /etc/cron.daily/update_glsa_programs.cron )
#! /bin/sh### Update the portage tree and the glsa packages via pkgcore
# spew a status message echo $(date) "start to update GLSA" >> /tmp/cron-update.log
# Sync only portage pmaint sync /usr/portage
# security relevant programs pmerge -uDN @glsa > /tmp/cron-update-pkgcore-last.log || cat \ /tmp/cron-update-pkgcore-last.log >> /tmp/cron-update.log
# And keep everything working revdep-rebuild
# Finally update all configs which can be updated automatically cfg-update -au
echo $(date) "finished updating GLSA" >> /tmp/cron-update.log
And here's my weekly cron - executed every saturday night (in /etc/cron.weekly/update_installed_programs.cron ):
#!/bin/sh### Update my computer using pgkcore, ### since that also works if some dependencies couldn't be resolved.
# Sync all overlays eix-sync
## First use pkgcore # security relevant programs (with build-time dependencies (-B)) pmerge -BuD @glsa
# system, world and all the rest pmerge -BuD @system pmerge -BuD @world pmerge -BuD @installed
# Then use portage for packages pkgcore misses (inlcuding overlays) # and for EMERGE_DEFAULT_OPTS="--keep-going" in make.conf emerge -uD @security emerge -uD @system emerge -uD @world emerge -uD @installed
# And keep everything working emerge @preserved-rebuild revdep-rebuild
# Finally update all configs which can be updated automatically cfg-update -au
For a long time it bugged me, that eix uses a seperate database which I need to keep up to date. But no longer: With pkgcore as fast as it is today, I set up pquery to replace eix.
The result is pix:
alias pix='pquery --raw -nv --attr=keywords'
(put the above in your ~/.bashrc)
The output looks like this:
$ pix pkgcore
* sys-apps/pkgcore
versions: 0.5.11.6 0.5.11.7
installed: 0.5.11.7
repo: gentoo
description: pkgcore package manager
homepage: http://www.pkgcore.org
keywords: ~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86
It’s still a bit slower than eix, but it operates directly on the portage tree and my overlays — and I no longer have to use eix-sync for syncing my overlays, just to make sure eix is updated.
Aside from pquery, pkgcore also offers pmerge to install packages (almost the same syntax as emerge) and pmaint for synchronizing and other maintenance stuff.
From my experience, pmerge is hellishly fast for simple installs like pmerge kde-misc/pyrad, but it sometimes breaks with world updates. In that case I just fall back on portage. Both are Python, so when you have one, adding the other is very cheap (spacewise).
Also pmerge has the nice pmerge @glsa feature: Get Gentoo Linux security updates. Due to it’s almost unreal speed (compared to portage) checking for security updates now doesn’t hurt anymore.
$ time pmerge -p @glsa
* Resolving...
Nothing to merge.
real 0m1.863s
user 0m1.463s
sys 0m0.100s
It differs from portage in that you call world as set explicitely — either via a command like pmerge -aus world or via pmerge -au @world.
pmaint on the other hand is my new overlay and tree synchronizer. Just call pmaint sync to sync all, or pmaint sync /usr/portage to sync only the given overlay (in this case the portage tree).
Using pix as replacement of eix isn’t yet perfect. You might hit some of the following:
pix always shows all packages in the tree and the overlays. The keywords are only valid for the highest version, though. marienz from #pkgcore on irc.freenode.net is working on fixing that.
If you only want to see the packages which you can install right away, just use pquery -nv. pix is intended to mimik eix as closely as possible, so I don’t have to change my habits ;) If it doesn’t fit your needs, just change the alias.
To search only in your installed packages, you can use pquery --vdb -nv.
Sometimes pquery might miss something in very broken overlay setups (like my very grown one). In that case, please report the error in the bugtracker or at #pkgcore on irc.freenode.net:
23:27 <marienz> if they're reported on irc they're probably either
fixed pretty quickly or they're forgotten
23:27 <marienz> if they're reported in the tracker they're harder
to forget but it may take longer before they're
noticed
I hope my text helps you in changing your Gentoo system further towards the system which fits you best!