@HEADER@

Paludis, the Other Package Mangler

Cache Files

Overview

This document explains the various cache options that are available for Paludis. Correct use of the cache can offer huge speed benefits; however, using the different cache options impose various restrictions about how other package managers can be used in parallel with Paludis.

The Provides Cache

Loading the VDB (information about installed packages) is slow on systems that have several hundred packages installed. The VDB format cannot currently be changed because lots of ebuilds rely upon it working (solutions involving hacking in a fake VDB with real data elsewhere are considered far too impractical). This is a nuisance, because the VDB needs to be fully loaded for most tasks.

Many common tasks only require a full VDB load to check for PROVIDE entries. If, instead of forcing a full scan to load PROVIDEs, we cache this data in a single file, various common tasks become an order of magnitude faster. Paludis supports this option via a key called provides_cache in the configuration files for vdb format repositories.

To enable this cache, set provides_cache = ${location}/.cache/provides . To disable it, set provides_cache = /var/empty . By default, the provides cache is disabled but generates a warning message suggesting that the user explicitly enable or disable it.

Warning: If you enable the provides cache, and then go on to install or uninstall packages using another package manager, you must run paludis --regenerate-installed-cache before performing any other operation. You should also run this command after turning on the cache for the first time, and if Paludis is interrupted during an install or uninstall if it has started to modify the live filesystem.

The Names Cache

Turning an unqualified package name, like vim, into a qualified name, like app-editors/vim, involves scanning every category directory. This can take several seconds on a cold filesystem cache. Paludis can cache unqualified to qualified name mappings for ebuild and vdb repository formats. This makes certain common tasks much faster.

To enable this cache, set names_cache = ${location}/.cache/names . To disable it, set names_cache = /var/empty . By default, the names cache is disabled but generates a warning message suggesting that the user explicitly enable or disable it.

Warning: If you enable the names cache, and then go on to sync or otherwise modify the repository in question manually or with another package manager, you must run paludis --regenerate-installable-cache (for ebuild repositories) or paludis --regenerate-installed-cache (for VDB repositories). You should also run this command after turning on the cache for the first time, and if Paludis is interrupted during an install, uninstall or sync if has started to modify the live filesystem.

The Metadata Cache

Extracting metadata (description, dependency information and so on) from an ebuild is slow -- it involves invoking bash with a considerable amount of supporting code. To avoid this penalty, a centrally generated metadata cache is distributed with the official tree in the metadata/cache directory (Paludis can be told to look elsewhere by using the cache reposiory key). For third party repositories and non-rsync users, this metadata cache may not be available.

Paludis can generate metadata cache locally on demand. This will not speed up the first time cache is accessed for a particular ebuild, but subsequent invocations will be several orders of magnitude faster. To enable this cache where it is needed, set the write_cache key in an ebuild format repository. Recommended values are /var/cache/paludis/metadata or /home/username/.paludis-cache. Note that Paludis will place the write cache for a repository into a subdirectory named for that repository, so specifying the same write_cache for every repository is acceptable.

@FOOTER@