Void Linux: Creating Binary Packages Using xbps-src

Introduction

While not delving into its technical features, I did want to experiment with xbps-src as it is one of the cornerstone features of Void that make it unique and worth using for a non casual user. At first, I chose to package Firefox Developer Edition, a program that isn't available from Void's free or non-free binary repositories. It is also not available in Void's source Github repository, a large component of Void's source package management system. On distributions where FDE is not available, I typically use a script based on Installing Multiple Versions of Firefox Including Multiple Profiles to install it. In this case it was a perfect candidate, besides Kmail built for Plasma 5 -- which would be too complicated for a first attempt, with which to try xbps-src.

Unfortunately, this attempt was not successful because, although Void is rolling, it is not bleeding edge as far as Mozilla associated packages are concerned (see below), and a recent enough Mozilla dependency was not available. So I thought Opera Developer would be a simpler alternative. Again, this had an obsolete dependency (see below), which I think is a fault of Void, whereas the FDE complication may not be.

Prepare System

In order to use xbps-src and its associated tools, the system has to be prepared.

XTOOLS

The xtools package provides some useful utilities specifically for xbps-src and some that are generally useful. It can be installed with:

sudo xbps-install xtools

Void Linux Github Repository

The core of Void's method of organizing source packages directories, build directories, and associated build system paths is a clone Void's Github repository of source packages. The clone can be created on the local system -- for local use, not for contributing to Void -- with:

git clone https://github.com/voidlinux/void-packages

This will create the directory void-packages with the source tree of all Void packages in void-packages/srcpkgs. The following representation of void-packages is reproduced from the Github repository's README.

     /void-packages
        |- common
        |- etc
        |- srcpkgs
        |  |- xbps
        |     |- template
        |
        |- hostdir
        |  |- binpkgs ...
        |  |- ccache- ...
        |  |- distcc- ...
        |  |- repocache ...
        |  |- sources ...
        |
        |- masterdir
        |  |- builddir -> ...
        |  |- destdir -> ...
        |  |- host -> bind mounted from 
        |  |- void-packages -> bind mounted from 

Then install the bootstrap packages, which are required to build the binary packages in isolation, with the following:

cd void-packages

./xbps-src binary-bootstrap

This installs the binary bootstrap packages; if the user desires building the bootstrap packages themselves, bootstrap can be used instead of binary-bootstrap. Void uses some utilities -- two that are part of XBPS and one that is not -- to manage the chroot and bind mount of the build environemnt. I chose the xbps-uchroot utility. In order to enable it, I executed:

# cd /usr/bin/
$ echo XBPS_CHROOT_CMD=uchroot >> etc/conf
# chown root:xbuilder xbps-uchroot
# chmod 4750 xbps-uchroot
# usermod -a -G xbuilder brook

Build

After preparing the system as above, for at least building for local installation -- not for contributing changes to the Void repos -- we are ready to build some packages. The basic steps I used are to first make the template. This is the script that provides the build "recipe" as does RPM distributions' .spec file, Arch's pkgbuild, and Gentoo's .ebuild. One of the xtools utilities can create a skeleton template with some prepopulated fields with:

xnew opera-developer

The completed template file should include the sha256sum of the source archive, then the source archive can be automatically downloaded and its checksum compared to that indicated in the template with:

xgensum -f srcpkgs/opera-developer/template

Finally, the package is built with:

./xbps-src pkg opera-developer

The same series of commands used as for Opera Developer will build the Firefox Developer Edition binary.

xnew firefox-developer-edition

xgensum -f srcpkgs/firefox-developer-edition/template

./xbps-src pkg firefox-developer-edition

After creating the skeleton template with the xnew command, using the template for the Void packaged Firefox as a guide, I modified it with appropriate changes, most importantly the very different URL used in the distfile parameter due to fewer available options for obtaining the FDE source packages. The final version of the template I used is available here.

Result

The above process places the built binary package in void-packages/hostdir/binpkgs. This package can be installed with, in the case of Opera Developer version I built,

sudo xbps-install --repository=./hostdir/binpkgs opera-developer-54.0.2920.0_1

or with one of the xtools

xi opera-developer-54.0.2920.0_1

Sadly in both of my attempted builds, there were unresolvable problems. In the case of Opera Developer, the build completed successfully, but the package could not be installed due to an unresolved dependency on rpi-userland>=0.0.0.0.20150907_1. This dependency, to my knowledge was not created by the Opera source package, and it certainly was not required by the template itself, but by void-packages/common/shlibs.

In the case of Firefox Developer Edition, the template I used as a guide, the Firefox template in Void srcpkgs, indicates an nss of version >=3.35, which is also the version available in Void srcpkgs, however it seems that Mozilla requires version >=3.36.1 for this version of FDE, and late in the build process there is an error indicating that the nss is not installed or the version is too old. There was no problem, however, with the build time dependency of the nss development package.

Conclusion

Although the builds were not successful, this experiment instilled a very positive impression of the xbps-src program itself. However, some of the infrastructure, such as the one with void-packages/common/shlibs which creates a systemwide dependency on an obsolete package, and the lack of a current nss by Mozilla standards, was dissapointing.