HOWTO pkgcore quickstart guide
From Gentoo Linux Wiki
| Installation • Kernel & Hardware • Networks • Portage • Software • System • X Server • Gaming • Non-x86 • Emulators • Misc |
Contents |
[edit] Preface
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.
[edit] 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.
[edit] 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.
[edit] 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>
[edit] 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.
[edit] 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.
[edit] Searching
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.
- emerge -s python :: pquery -vnm '*python*'
- emerge -S <package> :: pquery -vnS <package>
- equery belongs /bin/ls :: pquery --owns /bin/ls
- equery check :: not implemented yet
- equery depends <package> :: pquery --vdb --revdep dev-lang/python
- equery depgraph :: not implemented yet
- equery files <package> :: pquery --contents -m <package>
- equery hasuse <package> :: pquery --vdb --has-use <package>
- equery list python :: pquery --vdb -m '*python*'
- equery size :: not implemented yet
- equery uses <package> :: pquery --attr use -m python
- No equivalent :: pquery --license GPL-2 --vdb
- No equivalent :: pquery --maintainer seemant
[edit] Sets
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:
- system - same as portage
- world - same as portage
- version-installed - versioned-installed is a set of all cpv's (->WTF IS A cpv?) from the vdb (->WTF IS A vdb?). This is useful for --emptytree.
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.
- installed - installed is an unversioned set, but is slotted.
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.
- vuln - Packages that are vulnerable to security bugs.
[edit] 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
[edit] Portage Equivalents
[edit] New in pkgcore
- --ignore-failures
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.
- --preload-vdb-state
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.
[edit] Moved, in pmerge
- --depclean
Replaced with --clean
- --with-bdeps
Replaced with --with-built-depends
[edit] Moved out of pmerge
- --regen
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:
- --info
pconfig is the closest equivalent at the moment- rather verbose.
- --config
This may be implemented in pmaint in the future.
- --prune
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.
- --resume Not yet implemented.
- --skipfirst Not yet implemented.
- --metadata Not implemented- pkgcore doesn't need cache localization. If the user is after copying cache data around, pclone_cache can be used.
- --fetch-all-uri Not yet implemented.
- --buildpkg Not yet implemented.
- --getbinpkg Not yet implemented.
- --getbinpkgonly Remote Binhost v1 support will not be implemented in pkgcore, instead favoring the genpkgindex approach Ned Ludd (solar) has created.
Reasoning for this comes down to two main reasons-
- Design of v1 allows for collisions in the package namespace, category is ignored. Further, this collision isn't easily detectable- pulling mysql-5.0 from the server may get you virtual/mysql-5.0 or dev-db/mysql-5.0
- Design is god awfully slow. To get the metadata for a binpkg from an HTTP server, requires (roughly) a HEAD request (tbz2 length), ranged GET request to grab the last 16 bytes for the XPAK segment start, another ranged request to pull the metadata.
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.
- --tree This is formatter dependant, it may be included in 0.3.
- --alphabetical and --columns won't be implemented in pkgcore.
- --changelog* At some point will be accessible via pquery.
