Description: | Extensible Pacman wrapper. |
Latest Version: | 2016 |
Source Code: | src/ |
Architecture: |
|
Dependencies: |
|
Arch Repositories: |
|
Tags: |
Pacboy is a Pacman wrapper and extender that emerged as a generalization of Powerpill, Bauerbill, Pbget, etc. Its key features are:
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:
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 http://xyne.archlinux.ca/repos/. 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:
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).
--rpc-listen-all=false
option to restrict the server to
listening on localhost. For a full description of the options, see the
Aria2 documentation.
{"port": 6800, "token": null}
. Leave
“token” as null to use a random token each time the server is launched.
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
.
null
,
Pacboy will check if the environment variable SUDO_USER
is
set and use it to build if it is.
["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.
pacboy --pb-rebuild-vcs
.
A dictionary of values shared to load into the environment object passed to the extensions.
http://localhost:15678
. Either omit this or set it to
null
if there is no server.
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": {}
.
["^core/kernel$"]
. This can be
combined with a custom build snippet to applied custom options and
patches to the kernel.
["^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.
*
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"]
.
RepoWrapperFactory
followed by the names of the repos that
it supports. For example, AUR support can be enabled with
["AUR.AurPkg.AurRepoWrapperFactory", "AUR"]
.
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"]
.
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.
["/usr/bin/sudo"]