The bandit.conf file

The bandit.conf configuration file

The bandit.conf file is the configuration file that controls the behavior of the bandit in a phySystem.

Located at $BANDIT_HOME/etc directory, it is a bash script with configuration variables which is sourced every time a the bandit command is invoked. The file has four sections to configure the BANDIT itself, the HOST system, the BUILDER system and the final TARGET system.

The BANDIT section

BANDIT repositories

The bandit can download catalogs of bundles from remote repositories. Also, a local repository is provided by default for local system management. An ordered list of repositories is defined in the BANDIT_REPOSITORY_LIST variable.


Enabled catalogs

A number of catalogs and bundles can be available in the bandit directories. Use the BANDIT_CATALOG_LIST variable to select the enabled catalogs. Only these enabled catalogs will be searched, in the order listed, when a bandit command is issued.


Local directories

Set the local directories variables to control where the BANDIT libraries (BANDIT_REPOSITORIES and BANDIT_CATALOGS) and caches (BANDIT_XSOURCES, BANDIT_XBUILDS, etc.) will be stored. Logs are also stored by default in $BANDIT_HOME as controlled by the variable BANDIT_LOGS.

## Bandit local directories


Some packages when built from source (e.g. Libreoffice) may have trouble with very long file names in the build process. In such case, try changing BANDIT_WORK to a shorter directory name like /var/tmp or /tmp instead of the longer $BANDIT_HOME/var/tmp.

Remember setting the right filesystem permissions when any of these directories are set outside of BANDIT_HOME (e.g. to share cache directories). At least, give full permission to read and write to the phyglos group for these directories.

Output pager

Some bandit commands, like search can issue very long outputs. This output can be paged using the command specified in BANDIT_PAGER.

## Bandit pager
# none  - do not use a pager
# more  - default pager
# less  - use less as pager

Compilation options

These variables control how to compile from source code the package items of a bundle.

The variables MAKEFLAGS, CPPFLAGS, CFLAGS and CXXFLAGS are those of the GNU make and control how sources are compiled for the phySystem.

## Number of parallel build jobs
# -j2                  - use two parallel jobs
# -j$(( $(nproc)+1 ))  - use the number of CPU cores plus one
export MAKEFLAGS="-j$(( $(nproc)+1 ))"

## Compilation flags. See gcc documentation.
# WARNING: Add other compilation options with caution
# -march=native  - optimize for local hardware
# -O2            - set optimization level to 2
# -pipe          - pipe in memory instead of disk
# -w             - suppress most warnings
export CPPFLAGS="-w -O2 -pipe"
export CFLAGS=""

Testing options

The variable BANDIT_BUILD_TEST_LEVEL controls which tests are executed when building a package item from sources. This way a bundle can be raised either without running any build test or executing all the possible tests defined for each package.

## Test level for packages
# Select the level of testing when building packages
# 0 - No tests at all
# 1 - Essential tests (binutils, gcc, glibc, other core libraries...)
# 2 - Main tests (make, perl, python, ...)
# 3 - All tests (test every package with a test suite)
# 4 - All tests including optional tests (e.g. in toolchain)

Each package script can have defined a variable build_test_level. The bandit checks this value in build time and, when the script variable is equal or greater than the global BANDIT_BUILD_TEST_LEVEL, the function build_test() inside the script is executed.

Packing options

After the compilation of a source package, all helping files *.la are deleted by default, as defined by the BANDIT_KEEP_LA variable set to no by default. When a bundle needs to preserve these files (e.g. the phyglos-core bundle), the variable BUNDLE_KEEP_LA can be set to yes in the bundle description file to alter this global behavior for that specific bundle.

All packages compiled are finally packed and stored in the builds cache directory as defined in the main BANDIT_XBUILDS variable. These build packs take the final name from the source package plus a release tag value, which is defined in the BANDIT_RELEASE_TAG variable in this section. For building specific packages optimized for a given machine, the variable can be set to $(hostname). For using the generic binary, prebuilt pack set the variable to latest.

## Build pack options
# Default release tag for build packs
# Clobber with BUNDLE_RELEASE_TAG when building.

# Keep or remove \*.la files after each package build
# Clobber with BUNDLE_KEEP_LA.

System databases update options

After a bundle is installed, BANDIT will update the system databases (e.g, man pages, locate database, …). The default behavior is set using the variable BANDIT_UPDATE_SYSTEM_DB to yes.

For some bundles there is no need to update these databases because they do not add new commands or man pages. The variable BUNDLE_UPDATE_SYSTEM_BD can be set to no in the bundle configuration file to alter the global behavior set in the bandit.conf file.

## System databases update options
# Update system databases after a bundle

The HOST section

HOST unprivileged user

When raising the temporary BUILDER system, a temporary, unprivileged user is created in the HOST system in order to protect this system during the compilation. The variables BANDIT_USR and BANDIT_GRP control how this user is created in the HOST system.

## HOST unprivileged user for raising the BUILDER system
# This user is only used to create the BUILDER system, the set of crosscompiling tools

You can provide any name for the user provided that it does not exist. The group name will be also added if it does not exist.


The user BANDIT_USR will be deleted when issuing a bandit -s host clean command. Do not use an existing user that you want to preserve. The group is not deleted, tough.

HOST mount point of the TARGET partition

The TARGET system partition must be accessible from the HOST system. The variable BANDIT_HOST_TGT_MNT specifies a non-existing directory in the HOST system where the TARGET partition will be mounted when raising a new phyglos machine.

## HOST mount point for the TARGET partition or directory
# This mount point must not exist in HOST


When the TARGET is built as a directory instead of a partition type, there is no mounting of any partition and this is the directory where the TARGET is raised. See the TARGET section below.

HOST crosstools triplet

When the BUILDER is raised, a pseudo-crosscompiling process creates a new system compiler. This type of build is triggered by setting the following variables to a value different from the BUILDER triplets:

## HOST crosstools triplet
BANDIT_HOST_ARCH=$(uname -m)
BANDIT_HOST_TRIPLET=$(uname -m)-unknow-linux-gnu


Do not change thess values unless you know exactly what you are doing. There is no need to change thse values in usual operations.

The BUILDER section

Directory for the BUILDER filesystem

The BUILDER system filesystem resides inside the TARGET partition. The variable BANDIT_BUILDER_DIR specifies a directory in the BANDIT_HOST_TARGET_MNT partition where the temporary BUILDER system filesystem is built.

The value of this variable must be an absolute path that will be valid as seen either from both the HOST filesystem and for the TARGET filesystem.

## HOST directory for the BUILDER filesystem
# Path for BUILDER, as seen from both the HOST and BUILDER filesystems.
# Must be an absolute path starting with "/".

BUILDER crosstools triplet

When the BUILDER is raised, a pseudo-crosscompiling process creates a new system compiler. This type of build is triggered by setting the following variables to a value different from the HOST triplet ones:

## BUILDER crosstools triplet
BANDIT_BUILDER_TRIPLET=$(uname -m)-phyglos-linux-gnu


Do not change these values unless you know exactly what you are doing. There is no need to change these values in usual operations.

The TARGET section

TARGET system type

The TARGET system can be built on free disk partitions or on some directory.

Build the target in a partition if the final system is to be detached from the HOST system. i.e. by booting from that partition or because you are raising on a removable media.

Build the target in a directory when you plan to create a container image from the TARGET filesystem, i.e. exporting the directory to a Docker image.

## Type of TARGET system
# directory - build the TARGET in a HOST directory
# partition - build the TARGET in a HOST partition


You can always build on a directory and later on transfer the filesystem to a disk partition.

TARGET system partitions

The TARGET partition and the TARGET swap partition are defined using the variables BANDIT_TARGET_PART and BANDIT_TARGET_SWAP variables. These are the filenames of the partitions created when preparing the HOST system partitions. Set this values from none to /dev/sdb1 for example. During the raise process the BANDIT_TARGET_PART will be mounted onto the BANDIT_HOST_TGT_MNT directory as set in the previos HOST section.


These partitions will be initialized. Be sure you set the correct values before using this configuration file.

The default TARGET system filesystem type is ext4. For other filesystem types, the phyglos-kernel default configuration file needs to be properly configured.

A label for each partition is given by default. Check that these labels are not already in use for the HOST system and change them accordingly.

## TARGET partition
# CAUTION: Select the right partition to be initialized.
# This partition must exist before using BANDIT
# none     - no partition is used
# /dev/xyz - use partition /dev/xyz

## TARGET swap area
# WARNING: Swap partitions can be safely shared with other installed systems
# except if they use hibernation into that swap area
# none     - no swap partition is used
# /dev/xyz - use swap partition /dev/xyz

TARGET crosstools triplet

The TARGET system could be of a different type than the HOST system. To perform a crosscompiling raise these variables need to be set to the corresponding values for the TARGET architecture:

## TARGET crosstools triplet
BANDIT_TARGET_TRIPLET=$(uname -m)-unknow-linux-gnu


Do not change these values unless you know exactly what you are doing. There is no need to change these values in usual operations.

TARGET initialization

During the initialization process of the TARGET filesystem some files from the HOST filesystem are copied. Indeed, the actual BANDIT is copied from the HOST to the TARGET. Also, the BANDIT catalogs defined at the HOST are copied. To prevent, however, that a copy of the HOST localhost catalog is copied, the variable BANDIT_TARGET_COPY_LOCALHOST is set to no.

## TARGET initialization options
# Copy the HOST localhost catalog into the TARGET system:
# yes - the local catalog is copied from the HOST
# no  - a new, empty local catalog is copied from templates

To avoid copying the full HOST builds cache to the TARGET, the variable BANDIT_TARGET_COPY_XBUILDS is set to no by default.

# Copy the HOST builds cache into the TARGET system:
# yes - the builds cache is copied from the HOST
# no  - the builds cache in not copied