Project:Portage/FAQ
How can "blocks" between packages be resolved?
See the Blocked Packages section in the Gentoo Handbook.
Why is it that emerge does not update all packages?
By default, the dependency graph may not include some packages. For example, it will not include any packages that are listed in the output of emerge --pretend --depclean. It will also not include any build time dependencies for binary packages. If you would like to include such build time dependencies even though they are not strictly required, use --with-bdeps=y. You can set EMERGE_DEFAULT_OPTS="--with-bdeps=y" in /etc/portage/make.conf if you would like this option to be enabled by default. If you would like a specific package to be updated in any case, you can use emerge --noreplace <atom> to have it added to the world set.
After running emerge --deep --with-bdeps=y --update @world, it is a good idea to use emerge --pretend --depclean to see if there are any packages that it would remove. If that command shows a package that you would like to keep, use emerge --noreplace <atom> to have it added to the world set.
When you use emerge --depclean to remove unwanted packages, it is a good idea to run revdep-rebuild (from the app-portage/gentoolkit package) afterward.
Run man emerge to view the manual page which documents all emerge options.
How can I check for reverse dependencies of a package, to know if it can be safely uninstalled?
Run emerge --depclean --pretend --verbose [atom]... to see if there are any reverse dependencies for matched packages.
When you use emerge --depclean to remove unwanted packages, it is a good idea to run revdep-rebuild (from the app-portage/gentoolkit package) afterward.
Why does emerge --depclean sometimes remove system packages?
For system dependencies that are specified as virtuals, such as virtual/editor, it's common to have multiple packages installed that are capable of satisfying the dependency. In this case, redundant packages may be removed by emerge --depclean unless they are explicitly added to the world set. You can use emerge --noreplace <atom> to have a package added to the world set, and this will guarantee that this package will not be removed by emerge --depclean.
Why doesn't emerge account for reverse dependencies sometimes?
Complete accounting for reverse dependencies is time-consuming, and many users would be likely to complain about poor performance if this was the default behavior. So, reverse dependencies will often be neglected by dependency calculations unless the emerge --complete-graph (or --deep - the only difference is that --deep will consider upgrades) option is enabled.
You can set EMERGE_DEFAULT_OPTS="--complete-graph" in /etc/portage/make.conf if you would like this option to be enabled by default. Refer to the emerge manual page (run man emerge) for more information about the --complete-graph option.
Can I mount the Gentoo repository (/var/db/repos/gentoo) via NFS?
It is possible to share the Gentoo repository (/var/db/repos/gentoo) over NFS so that emerge --sync only needs to be run on an NFS server. However, even though NFS clients do not need to run emerge --sync, they must run emerge --metadata each time that the Portage tree is updated since otherwise their dependency calculations will slow down due to their metadata cache (located in /var/cache/edb/dep) becoming stale.
With versions of Portage >=2.1.5_rc6 there is never any need to run emerge --metadata as long as the user has not enabled
FEATURES="metadata-transfer" in make.conf. When metadata-transfer is disabled, metadata cache from the /var/db/repos/gentoo/metadata/md5-cache/ directory will be used directly. Run man make.conf to learn more about metadata-transfer.If you encounter problems with an NFS setup it is important that you ensure you have the proper locking daemons on both the NFS client machines and the NFS server machine. Portage uses hardlinks over NFS in an attempt to lock files; if the locking daemon fails to lock files Portage may complain about failed or stale locks. There is a script /usr/lib/portage/bin/clean_locks that can be used to clean out old lockfiles.
Why does emerge display "waiting for lock" messages?
The most common reason is due to FEATURES="parallel-fetch" which is enabled by default in /usr/share/portage/config/make.globals. Set FEATURES="-parallel-fetch" in /etc/portage/make.conf if you would like to disable this feature. Refer to the make.conf manual page (run man make.conf) for more information about possible FEATURES values.
If the emerge command is invoked multiple times concurrently, or if DISTDIR location is on a shared network file system, this may also trigger similar "waiting for lock" messages. Such locks are necessary in order to prevent interference between concurrently running processes.
Why does the @preserved-rebuild set contain packages that have already been rebuilt?
This is a common problem which indicates that the build system for the given ebuild causes the package to inappropriately link against the old (preserved) version of the library, instead of the new one. As a workaround, you can manually remove the old library (such as libreadline.so.5.2) and then run revdep-rebuild in order to rebuild the packages which linked against it. A list of all preserved libraries may be obtained from portageq list_preserved_libs /.
When packages are built in parallel with the --jobs option, why aren't some packages installed immediately after they have finished building?
As a safety precaution, installation actions for system packages and their deep dependencies are executed only when no other packages are building. This behavior is required in order to avoid cases like bug #256616 (unspecified system dependencies) and bug #259954 (temporarily unsatisfied system dependencies).
How do I configure environment variable settings that apply only to specific packages?
Put an entry such as sys-libs/glibc debug.conf in /etc/portage/package.env, and put your variable settings in /etc/portage/env/debug.conf (using the same format as make.conf). An example debug.conf file might appear as follows:
debug.confCFLAGS="${CFLAGS} -ggdb"
CXXFLAGS="${CXXFLAGS} -ggdb"
FEATURES="${FEATURES} installsources splitdebug"
What should I do when emerge reports a lot of dependency conflicts involving built slot-operator (foo/bar:X/Y=) dependencies?
Built slot-operator (foo/bar:X/Y=) dependencies tend to introduce a lot of noise when emerge dependency calculations fail. If you encounter this problem, then you should temporarily add the emerge --pretend and --ignore-built-slot-operator-deps=y options to your emerge command, in order to suppress noise related to built slot-operator dependencies so that it is easier to identify issues that are more important. This problem is tracked by bug #598503.
It addition to the --pretend and --ignore-built-slot-operator-deps=y options mentioned above, it can also be helpful to temporarily add --backtrack=0 to the emerge options, so that the dependency resolver does not spend extra time backtracking before it ultimately fails. Also, it can be helpful to use --ask instead of --pretend, so that emerge will ask you if you would like to write configuration changes that have been automatically generated by the --autounmask option.
Also see Built Slot Operator Dependency Conflicts.
What should I do if emerge fails to solve conflicts when there are "no parents that aren't satisfied by other packages in this slot"?
This is a known issue, reported in bug #595224. If the conflict solely involves built slot-operator (foo/bar:X/Y=) dependencies (the --verbose-conflicts option can help you determine this), then you should temporarily add the emerge --pretend and --ignore-built-slot-operator-deps=y options to your emerge command, as discussed in the answer to the previous question. Otherwise, it may be necessary to solve the conflict by masking one of the packages with package.mask.
Why is there a dependency conflict when I attempt to upgrade a single package?
Attempts to upgrade single packages will often trigger dependency conflicts because emerge does not have an option to specify that it should automatically update reverse dependencies as needed. As discussed in bug #559354, there are plans to implement an option for automatically update of reverse dependencies. Meanwhile, the recommended practice is to update all packages together (after each emerge --sync operation), using a command such as emerge --deep --newuse --update @world.