Before you install a package, you usually look for it via Portage's search capabilities. Portage's emerge utility has
--searchdesc options, but using them is not enjoyable, because they take a long time to run. That's why we've seen the emergence of third-party search front ends for Portage, such as esearch and eix. Their common idea is to use their own search indexes to speed up searches. When using either utility, you have to rebuild the index after updating the Portage tree, and after installing and uninstalling software.
Of the two, eix works faster and has more capabilities. You can get information on the utility from its man page or by invoking
eix --help. To use eix to search for a package whose name contains
foo, simply invoke
Eix is a very flexible tool. It can give you more information on packages than esearch or
emerge -s. It can search through different fields (e.g. package name, category, or description), it can search for regular expressions or wildcard patterns, or do fuzzy searches, and its output can be configured for use in scripts.
Optimizing traffic usage
Updating your software can take a lot of network bandwidth. There are tools that help you decrease Portage's appetite. The most effective and well-known such tool is Deltup, which allows you to download deltas, or the differences between new and old versions of package source. That approach can save you up to 90% of the download size. The procedure for installing deltup is described in the Gentoo wiki.
Using Deltup has its drawbacks, however. Deltup will not resume fetching a delta if you lose a connection. Sometimes, the server generating the deltas is overloaded, and you must wait for a long time for it to generate your delta. Sometimes Deltup gets confused about which versions of packages you have. And, of course, generating a new package takes some CPU time. Still, Deltup should not break your system, so you should not be afraid to give it a try.
KDE maintainers generate the deltas for their packages themselves. This HOWTO describes using these deltas in Gentoo. There was a period when Portage supported a
kdexdeltas USE flag, so you did not need to patch your sources manually, but after KDE 3.5 this functionality was not updated, so the
kdexdeltas flag will not give you any advantage these days. Note that if you receive errors that report "digest verification failed" when using manually updated KDE sources, you can still install new KDE packages by using the
emerge --digest command.
You can use the power of deltas not only when updating source packages, but also when updating your Portage tree. Emerge-delta-webrsync allows you to download daily patches to the Portage tree, which is less traffic-consuming than using
emerge --sync. Just invoke
emerge emerge-delta-webrsync, and next time you need to sync your Portage tree, run
The Gentoo wiki provides more tips for users with poor Internet connections.
A new feature that came in Portage 2.1 can also help speed downloads. If you add the string
parallel-fetch to the FEATURES variable in /etc/make.conf, emerge will download some packages' source code while compiling others that are in the queue. This reduces installation time, especially if you emerge many packages.
Faster package compilation
Every time you install or update some software under Gentoo, you need to wait until its source is compiled. Portage supports a set of tools that try to decrease the compiling time of your packages.
Ccache makes it possible to speed up compilation of the same code by caching compilation results. Confcache is a similar tool for caching results of test configuration scripts (
./configure). It appeared at the same time as Portage 2.1, and still lacks full documentation, but it has been mentioned in the Gentoo Linux Newsletter. After spending some time in the unstable branch, it is now hardmasked, which means that confcache has some unresolved issues; if you try using the current confcache version (0.4.2) you will sometimes need to install some packages with the confcache feature turned off, or clean the confcache cache (
rm -rf /var/tmp/confcache).
Managing logs and configuration files
Another new feature in Portage 2.1 is the new logging framework. Many packages show notices while you emerge them, but you may not see them if you do not watch the emerge process. Now you just need to turn on elog, by adding these lines to /etc/make.conf:
# This sets what to log and creating the /var/log/portage/elog directory. Now, each package's emerge log will be saved in a separate file in the specified directory. You can find more info on configuring elog by inspecting the /etc/make.conf.example file. There are already GTK and QT graphical front ends for viewing these logs.
PORTAGE_ELOG_CLASSES="warn error log"
# And this is how to do it
After updating some packages you sometimes need to update their configuration files. The standard tool for this is etc-update, but there is a more handy and advanced utility -- dispatch-conf. It automatically updates configuration files that have easy changes to comments, or that have not been changed between updates. It also allows you to redo any changes you made to configuration files by placing them into a version control system.
Would you like to know more?
If these few brief tips have whetted your appetite, you can learn more about most aspects of Portage from its handbook, official documentation, and the Gentoo wiki. If you have any further questions, you may find an answer on the Gentoo forums.