Gentoo Wiki


This article is part of the HOWTO series.
Installation Kernel & Hardware Networks Portage Software System X Server Gaming Non-x86 Emulators Misc

Please improve it in any way that you see fit, and remove this notice {{Cleanup}} from the article. For tips on cleaning and formatting see Cleanup process



This is by no means a complete pkgcore working guide. It is meant for those who wish to try a viable alternative to portage and for those who wish to get up-and-runing in seconds.

Lesson 1: About pkgcore

pkgcore is the latest of the new generation package manager. Although at time of writing it cannot replace portage completely due to external tools trying to invoke emerge directly. It was started by the 2.5 year former portage lead ferringb and is lead by a group of current developers, Gentoo, portage and otherwise.

Lesson 2: The idea behind pkgcore

pkgcore is very similar to portage. It is meant to be a drop-in replacement so it is easy to use and without any of the shortcomings of portage itself.

Lesson 3: Down to basics

The first command you will need to know is pmerge. Unsurprisingly it is the pkgcore equivalent of portage's emerge so all you need to do to download and install a package is pmerge <foo>

Everyday commands

Along with your basic pmerge comes your basic emerge commands. For the most part they are the same as portage's commands although the output is slightly more informative. For instance:

pmerge -h <foo> is --help
pmerge -a <foo> is --ask
pmerge -p <foo> is --pretend
pmerge -D <foo> is --deep
pmerge -v <foo> is --verbose
pmerge -u <foo> is --upgrade
pmerge -f <foo> is --fetchonly

These are the commands that most users will use in their everyday portage use.

Further Use

As with portage there are the commands that you will eventually use but are not in everyday useage

pmerge -C <foo> is --unmerge (warning, this may remove important packages)
pmerge -k <foo> is --usepkg - Prefer to use built packages
pmerge -K <foo> is --usepkgonly - Only built packages

There are many other similarities, use -h or --help to find out.


All search in pkgcore is done through pquery. pquery is used to extract various kinds of information about either installed or uninstalled packages. As you probably guessed from the name it is similar to equery, but it can do things equery cannot do and is alot more flexible.


Sets are phrases that are appended with -s. Available sets are dependant upon your configuration- majority of users still use make.conf configuration, which has five default sets, they consist of:

Example: If you have app/foo-1 and bar/dar-2 installed (and just those), versioned-installed would be a set containing -app/foo-1 and -bar/dar-2.

Unlike version-installed, installed can be used for "system update". Using pmerge -us installed over pmerge -u -s system -s world also has the advantage that dependency-orphaned packages are updated.

Example: If you had app/foo-1 slot 1, app/foo-2 slot 2, installed would be a set containing would be app/foo:1 app/foo:2.

Custom Sets

Doing this for a make.conf configuration is pretty simple. Just add a file to /etc/portage/sets, containing a list of atoms. The set name is the filename.

Example: Making a kde set:

pquery 'kde-*/*' --no-version > /etc/portage/sets/kde-set pmerge -uDs kde-set

Portage Equivalents

New in pkgcore

Ignore resolution/build failures, skipping to the next step. Think of it as the equiv of --skipfirst, just without the commandline interuption.

Goes without saying, this feature should be used with care- primarily useful for a long chain of non critical updates, where a failure is a non issue.

Good example of usage is if you want to build mozilla-firefox and openoffice during the night- both take a long while to build (including their deps), and the user is after getting as many packages built for the targets as possible, rather than having the 5th build out of 80 bail out even attempting the other 75.

Long term, this feature will likely be replaced with a more fine tuned option.

This preloads the installed packages database causing the resolver to work with a complete graph, disallowing actions that confict with installed packages. If it's disabled, it's possible for the requested action to conflict with already installed dependencies that aren't involved in the graph of the requested operation.

Moved, in pmerge

Replaced with --clean

Replaced with --with-built-depends

Moved out of pmerge

To regenerate run pmaint regen <repo-name> -j <# of processors>, which scales around .9x linear per proc, at least through 4x for testing.

No pkgcore equivalent:

pconfig is the closest equivalent at the moment- rather verbose.

This may be implemented in pmaint in the future.

Currently not implemented; portages implementation of it ignores slots, trying to force a max version for each package- this is problematic however since it can remove needed slotted packages that are of a lesser version.

Any package that requires slotting (automake for example) generally will be screwed up by emerge --prunes behaviour.

Long term intention is to implement this functionality safely- effectively try to minimize the resolved dependency graph to minimal number of packages involved.

Reasoning for this comes down to two main reasons-

That's per package. Can cache, but the roundtrips add up quickly.

The package namespace collision issue is the main reason why v1 support will not be added to pkgcore; v2 addresses both issues thus is the route we'll go.

Retrieved from ""

Last modified: Fri, 20 Jun 2008 10:46:00 +0000 Hits: 8,811