Test environment

Testing your ebuilds (see also Package testing) can be a tedious task. Beside a simple re-emerge of the package in question, to see whether it merges successfully, a good testing practice usually needs to take one or more of the following questions into account:


 * Having a clean gentoo installation to test with: Using your day to day desktop, might miss on dependencies, which you happen to have installed already and thus producing false positives, i.e. letting your ebuild successfully install, while on a new system it would have been failed due to missing dependencies.
 * An exhaustive testing of all possible USE flag combinations: For ebuilds with only a few USE flags, this can be done easily by hand. For packages with a lot of USE flags, such an approach is error-prone. You might be better by writing a shell or python script to enumerate all the possibilities.
 * Profile testing: Here testing of default vs. hardened and multilib vs. no-multilib profiles is of interest. It may for example uncover problems with PIC/PIE code in hardened profiles or problems of missing proper multiclassing in the ebuild. Usually you don't want to switch profiles just for the purpose of testing an ebuild.
 * Keyword testing: This requires the proper hardware and is done by the arch projects.

So to run proper and efficient tests for your ebuild, a dedicated test environment seems necessary. There are several options for this, like using a chroot environment, VM's, a containerized enviroment or even dedicated hardware. The table below summarizes some of the pros and cons of these options.

Using Docker containers for ebuild testing
is a python script for testing ebuilds within a Docker container. The script compiles a docker container with the parameters passed at invocation time and either installs the specified package or puts the user into a shell inside the container. Usage of the script is simple (see http://ebuildtester.readthedocs.io for more details):

The  option is mandatory, as well as use of either   or. You can pass in one or more additional overlays with the  option. The script maps the portage and overlay dirs into the container, so changes to the files inside the container will affect the files outside the container on your file system. A one time use case for this script could look something like

assuming, the vtk-8.0.1.ebuild file has been modified in a local repository at.

Using LXC containers for ebuild testing
These instructions make use of unprivileged LXC containers.

Then for Distribution, choose gentoo; Release, choose current; and Architecture, choose amd64.

When it completes, start up the container with,

Then configure a basic development environment using the recommended tools.

To stop the container,

To clone the container for working on a particular ebuild,

To delete it when finished,