2022-07-15 12:40 UTC
  • Xyne


Description: Extensible Pacman wrapper.
Latest Version: 2016
Source Code: src/
  • any
Arch Repositories:
  • [xyne-any]
  • [xyne-i686]
  • [xyne-x86_64]


Pacboy is a Pacman wrapper and extender that emerged as a generalization of Powerpill, Bauerbill, Pbget, etc. Its key features are:

  • Fast downloads (packages, PKGBUILDs, package sources) via Aria2c.
  • Generalized API to support arbitrary repo extensions. You can add build support to pacman sync repos or create build-only third-party repos such as the AUR, CPAN, etc.
  • Associate packages with repos to always update those packages from those repos regardless of repo order.
  • Configure which packages should always be built and which should never be built.
  • Rebuild all rebuildable installed VCS packages.
  • Download PKGBUILDs and source files for all supported packages (official repos, AUR, and any others supported by an extension). These downloads will be run in parallel (including the source file downloads, if the option is passed).
  • Generated build scripts are fully customizable via per-package code snippets so users can apply patches, use custom build locations, etc., for any package.

Official Extension Modules


This module is included in python3-xcpf along with XCPF.Pacboy. It extends Pacboy with access to ABS so you can build all official Arch Linux packages or just download their PKGBUILDs and sources.

This module is included in python3-aur. It provides an extension for the AUR.



pacboy extension - Pacboy extension modules


Pacboy can be extended with build support for binary Pacman repos and third-party sources. This requires the implementation of a few classes in a Python 3 module. Basically, Pacboy needs access to essential package metadata (name, version, dependencies and a few others) along with a way to get it and the PKGBUILDs.


Under no circumstances should you run makepkg or mksrcinfo on third-party PKGBUILDS without prompting the user. Figure out another way to get the metadata that you need, such as requesting the PKGBUILD provide to provide SRCINFO files (which should be easy to do).

The only PKGBUILDs that may be run with makepkg or mksrcinfo are the official PKGBUILDs from Arch Linux as these are implicity trusted by pacman and ABS.

If your extension parses your own PKGBUILDs without third-party input then that may be acceptable, but this must be made clear to the user when distributing your extension.


To add build support to a Pacman binary repo (official or custom), i.e. one that you can already use with vanilla Pacman, the following must be subclassed:

  • XCPF.Pkg.Pkg
  • XCPF.RepoWrapper.BuildExtender
  • XCPF.RepoWrapper.BuildExtenderFactory

Check the documentation in the source code for each class’s methods. For a reference implementation check XCPF.PacboyExtXac which adds build support for the pacman binary repos on This implementation is based on downloadable SRCINFO and PKGBUILD archives and is relatively simple.

If the target repo website is able to provide downloadable SRCINFO files and PKGBUILD archives then you can just subclass XacBuildExtender and override the srcinfo_url and pkgbuild_archive_url methods.

XCPF.PacmanRepoWrapper may also be instructive but it is far more complicated due to the way official package metadata is spread across multiple interfaces (e.g. the website interface must be accessed to determine the PKGBASE, the website must be scraped for PKGBUILD downloads, etc.) In the future this will hopefully be simplified.


To create a completely new repo interface to a third-party repo that requires package building (e.g. the AUR), the following must be subclassed:

  • XCPF.Pkg.Pkg
  • XCPF.RepoWrapper.RepoWrapper
  • XCPF.RepoWrapper.RepoWrapperFactory

The source code comments are the best source of information. For a reference implementation, check AUR.RepoWrapper in python3-aur. Again, due to shortcomings in the AUR’s interface this implementation is more complicated than it should be but it will hopefully be simplified with a future AUR update.


.SRCINFO is the current common format for package metadata. If possible, retrieve or generate .SRCINFO files and use the parser in XCPF to get the package metadata. All that’s needed then is to generate the PKGBUILD and related files. The Xac extension provides SRCINFO files and PKGBUILD archives via the web interface, for example.

Keep in mind that there is a distinction between package bases and package names. If a repo provides split packages then SRCINFO and PKGBUILDs should be provided for each package base and the subclass of XCPF.Pkg.Pkg must be able to determine the package base.

The download job data structures are a little tricky at first but very versatile. They provide a way to group multiple downloads together as a single job that either succeeds or fails, with post-download transformation of the output if necessary (e.g. archive extraction, post-download PKGUILD generation). Check the Xac extension for the most accessible example along with the help functions such as source_array_download_jobs in XCPF.RepoWrapper.

Cache downloads when possible to speed up subsequent operations. For example, if an archive needs to be downloaded with the PKGBUILD to generate SRCINFO, cache the archive in case the PKGBUILD is requested in a later operation. The environment object provides the time-to-live parameter.



pacboy.json - Pacboy configuration file


The Pacboy configuration file is a plain JSON file. By default it is located at /etc/pacboy/config-pacboy.json. The main object is a dictionary where each key is considered a section below.


Note that all section names are in lower case in the file. Upper case may appear in the man page during automatic conversion of the markdown file. For example, “aria2” should appear in the configuration file, not “ARIA2”.


Configuration for the Aria2 RPC server(s) that will be used to download packages using parallel and segmented downloads. Running servers will be detected and used, otherwise servers will be started and stopped as needed.

By default, launched servers are restricted to localhost for security reasons. Some operations will require root privileges to save files in restricted directories (e.g. the Pacman sync database and cache directories).

A list representing the aria2c command and arguments to use when launching the download server. By default this includes the --rpc-listen-all=false option to restrict the server to listening on localhost. For a full description of the options, see the Aria2 documentation.
A dictionary specifying the port and token to use for server with non-root privileges: {"port": 6800, "token": null}. Leave “token” as null to use a random token each time the server is launched.


A boolean. If True, Pacboy will install all target binary packages before building other packages, including binary packages in the build list. Without this option, packages will be installed in sequential groups between builds as required by the dependency tree. The reason for this option is that the sequential operation may replace “pacman -Su” with multiple “pacman -S …” commands. If for some reason the installation should not be split this way, the option is necessary. There is also a matching command-line option.
A dictionary with the following keys: * build: A path to the default build snippet. See pacboy --pb-snippet-help for details. * custom build: A list of pairs of regular expressions and paths. The regular expressions will be matched against fully qualified pkgnames (e.g. “core/pacman”) in order. If one matches then the associated snippet will be used for that package. For example, "custom build":[["-git$", "/path/to/git/snippet"], ["-hg$", "/path/to/mercurial/snippet"]] could be used to assign a custom snippet for building all Git packages and another custom snippet for all Mercurial package. This can be used to apply patches, select other branches, change configuration options, etc. See pacboy --pb-snippet-help for details. * prologue: The beginning of the build script. This should specify the hashbang on the first line. * epilogue: A script to concatenate to the end of the build script. This may be null.
The system user as which to run the build scripts. If null, Pacboy will check if the environment variable SUDO_USER is set and use it to build if it is.
VCS download command
A list giving the download command for VCS sources in PKGBUILDs. By default, this uses a supplied script that internally uses makepkg’s backend to ensure compatibility with makepkg: ["makepkg-download_vcs_sources", "-o", "%OUTDIR%", "%URI%"]. This will be inserted directly into the build snippets so all variables supported by the snippets are supported in this command.
VCS patterns
A list of regular expressions for matching VCS package. This is used to determine build targets with pacboy --pb-rebuild-vcs.


A dictionary of values shared to load into the environment object passed to the extensions.

Time-to-live of cached data.
The URL of a Pacserve server to use, e.g. http://localhost:15678. Either omit this or set it to null if there is no server.

foreign config

A dictionary of configuration objects for enabled extensions. A class’s configuration object should appear under its own fully qualified name to avoid cluttering the namespace, e.g. "XCPF.PacmanRepoWrapper.OfficialBuildExtender": {}.


A list of regular expressions that will be matched against qualified target pkgnames (e.g. “core/foo”). If there is a match, the package will be built if possible. For example, to always build the kernel when doing a system upgrade, use ["^core/kernel$"]. This can be combined with a custom build snippet to applied custom options and patches to the kernel.
The same as build but packages that match will never be built.
repo associations
A list of regular expression-reponame pairs that can be used to always install a package from a target repo. For example, if package “foo” exists in the core repo but you would like to always install it from a custom repo “bar” regardless of the repo order, you could use ["^foo", "bar"]. These patterns are matched against the unqualified pkgname if it appears in the build targets. Explicitly passing a qualified pkgname on the command-line will override this, e.g. “pacman -S core/foo” will install “foo” from core even if there is a matching pattern.


The path to the default pacman configuration file.
The path to the pacman executable.


A list of repos to enable. This also configures the order in which package targets are satisfied. * will be expanded to all of the repos enabled in the Pacman configuration file. For example, to add all of the currently enabled Pacman repos and the AUR, use ["*", "AUR"].
repo wrapper factories
A list of lists to enable non-Pacman repositories. Each sublist begins with the fully qualified Python name of a subclass of RepoWrapperFactory followed by the names of the repos that it supports. For example, AUR support can be enabled with ["AUR.AurPkg.AurRepoWrapperFactory", "AUR"].
build extender factories
A list of lists to add build support to Pacman repositories. Each sublist begins with the fully qualified Python name of a subclass of BuildExtenderFactory followed by the names of the repos that it supports. For example, build support can be added to the official Pacman repos with ["XCPF.Repo.OfficialBuildExtenderFactory", "core", "extra", "community", "multilib"].
An extension of the Usage directive from the Pacman configuration file (see man pacman.conf) to non-Pacman repos. This is a dictionary of repo names mapped to lists, the elements of which are the same as Pacman’s Usage parameters. For example. to restrict AUR usage to searches, use "AUR": ["Search"]. For Pacman repos, this setting overrides the setting in the Pacman configuration file if present.


A list specifying the command to use when invoking sudo. By default, ["/usr/bin/sudo"]
echo | sed 's/\./@/'
XHTML 1.0 Strict CSS level 3 Atom 1.0