Pbins
Binary package support is currently extremely experimental. Be sure to read this entire document carefully and be aware that you will encounter bugs, some of which may leave your system unbootable or broken beyond repair.
Format Overview
Paludis uses its own format for binary packages built from ebuild or exhereses. This format is known as 'pbin'. It is not in any way compatible with Portage's tbz2 packages, which we consider to be too broken to be worth handling.
A pbin comes in two parts. First, there is the pbin file itself, which is a small file containing metadata information. Second, there is the tarball containing the content of the package, along with environment information to allow pre- and post-install functions to be run as if the package were being installed from source.
pbin files should be considered to be more or less like an ebuild or exheres -- in particular, they are kept in a repository, which can be shared and synced using the normal mechanisms. There is nothing special about repositories that contain binary packages, and it is in principle possible to mix binary and source packages within an individual repository (although doing so is a bad idea).
Similarly, the content tarball is treated just like source tarballs for ebuilds and exhereses. It is stored in a distfiles directory rather than in the repository, and can be fetched from a remote location (which might be mirrored) when it is required.
Using a binary repository is just like using a normal ebuild or exheres repository, and does not require any special
configuration. The importance
setting may be of interest here, however -- using a high importance for a
binary repository will result in packages in that repository being preferred, whilst using a low importance will result
in binaries only being used when necessary or explicitly requested.
importance
is only considered when deciding between two packages with the same version. To avoid
ever using a package from a particular repository, a mask must be used.
Notes on libarchive
We use libarchive to create binary packages, and require version 3.0.4 or greater.
Creating Binary Repositories
If one wishes to create binary packages, either for local use or for distribution, then some additional configuration is required. In general:
- Create a new, empty repository, exactly as you would for an overlay containing ebuilds or a supplementary
repository containing exhereses. Give it a name, like
fred-bin
. Configure Paludis to use this repository as normal. - In addition, specify keys like the following in the configuration file (see the e repository documentation for full details):
binary_destination = true binary_distdir = ${distdir} binary_keywords_filter = amd64 ~amd64
- If your binary repository is intended for non-local use, you may wish to use a different directory for
binary_distdir
, to make distributing generated tarballs simpler. In this case, you should also specifybinary_uri_prefix = http://yourserver/wherever
(ormirror://yourname/
and then also set up athirdpartymirrors
(Gentoo) ormirrors.conf
(Exherbo) as part of your repository.
Creating Binary Packages
Creating binary packages is done for two reasons.
- Creating binary packages may be a direct goal, either for local use or for publishing. In this case,
cave resolve --make binaries
can be used. The--make-dependencies
option will likely also be of interest. - Creating binary packages may be a desired side effect, either to avoid building a package twice to install to
slash and a chroot, or just to have something around for possible use when installing a package normally. In this
case,
cave resolve --via-binary
is a more appropriate solution.
Creating binaries using the old paludis
client is not recommended, since it is not aware of the
subtleties of dependencies with binary packages.