Upgrading Packages

Overview
Emerge is the primary portage tool for package management. It allows you to install and remove packages as well as perform various other related tasks.

Update and etiquette
Emerge does not connect to the Internet to check for new package versions, it compares your current packages against your local portage database. You must synchronise this local database with the Gentoo package servers in order to make emerge aware of new software versions, otherwise emerge will never see software updates. You can synchronise it by doing :

Updating your system
Simply doing emerge world will most likely not have the desired result when attempting to upgrade your system. Often a better way to do this is by using :

Here is an explanation of the extra switches and what they do:


 * u: The update switch is often included for clarity, but is the default action when using the "world" or "system" package specifications.
 * a: (ask) This is highly recommended on any emerge. It will tell you what it's planning to do before it does it. This gives you a chance to scan the list to make sure nothing is terribly wrong.
 * v: (verbose)[optional] This gives you more verbose output. It is technically optional, but it is often helpful.
 * D: (deep)The world package is not a list of every single package on your system. Only the ones you have emerged. For example, if you do emerge gnome there will be many dependencies installed on you system as well as ; however, only gnome-base/gnome will be recorded in the world files. Using D scans through the dependencies for updates too.
 * N: (newuse)[optional] This is the most optional of them all. Essentially what it does is check for any changes in the USE flags. This would normally be the case if you changed something in or maybe . For example, if you added USE="java" in /etc/make.conf and mozilla-firefox was originally emerged with the default setting (-java), then adding N would cause this command to re-emerge mozilla-firefox with the new USE variables.  This should probably be used only when you want to rebuild all packages with changed useflags, which is not likely part of your routine updates. See USE Flags for more information.
 * e: [highly optional] This option pretends that nothing is installed, it is only useful when upgrading a part of your toolchain. The emerge -e command is perfectly equivalent to a stage 1 installation. Use it only if you know what you do. Check out this post for more information.

Tips for servers
On servers and other stable systems, it may not be desirable to upgrade everything on your system frequently. You should still upgrade those packages that have security vulnerabilities if you might be affected. This can be done with the following:

Apply the fixes for any vulnerabilities found that might affect your server.

It is also recommended to update your kernel frequently, since GLSAs are not issued for kernel vulnerabilities.

Checking for broken packages
Did you break anything during the upgrade? Use "revdep-rebuild" to find out.

This is highly recommended after any package update if this package is a dependency of another installed package.

Portage 2.2 (in rc at the time of this writing) handles this by itself with a feature called preserved-libs. emerge will not remove old .so files when upgrading until it determines that no binaries link against them. To rebuild all packages and (hopefully) cause portage to remove these, run:

Update config files
If emerge outputs :

You must update your configuration file. You can do this using an automated gentoo tool called dispatch-conf bundled in the gentoolkit package. Install it :

Once it is installed, launch it using

The tool will show you the modified configuration files and their modifications and allows you to use the new or the old one.

Using Genlop
Genlop is a tool that parses log files. Genlop can be used to find out how long your emerge world will take. A basic command to do this would be :

But you can add any number of portage switches from above to your emerge command.

Special Cases
There may be several cases where the above does not upgrade what you want. The main case is when you are using CVS packages like Enlightenment DR17. Note that this should be the exception, not the rule. You should avoid using CVS unless you are willing to accept the consequences that they may bring.

The reason this does not upgrade CVS packages is because the packages do not change versions (they stay at 9999 usually). Also this means that the dependencies cannot be checked in the proper way either. This is probably just as well anyways. CVS packages should be handled separately. Something like :

should do the trick.

Aktualizacja pakietów