BANDIT entities

The BANDIT entities

Besides performing a series of operations on its own components like searches and internal database log management, the BANDIT toolkit understands about other different types of entities on which it can perform different operations.

BANDIT repositories

BANDIT, once installed, comes with no software building instructions nor source code to build from. In order to get theses instructions and source or build packs, the BANDIT can reach a BANDIT repository and obtain what is needed from there.

The localhost repository

The localhost repository is a predefined repository which contains a localhost catalog where the local bundles can be defined. This repository is mainly used for the specific needs of the HOST system where it is installed.

The phyglos.org repository

The default remote repository used with BANDIT is the phyglos.org repository. It is enabled by default and contains the phyglos catalog but its use is not mandatory. It can be disabled and some other repositories can be configured instead.

BANDIT catalogs

Repositories contain information about BANDIT catalogs, which are a set of related BANDIT bundles distributed as a unit.

The localhost catalog

The localhost catalog is a basic catalog, intended for local bundles. This catalog can be used to copy bundles from other catalogs and then customize their functionality for the localhost own purposes. This way, when the remote catalog is updated, the local changes are not lost.

The phyglos catalog

The phyglos catalog is the BANDIT catalog that contains all the bundles needed to raise and manage the functionality of a phySystem, i.e.: a system running phyglos.

The phyglos catalog can also be used in other distributions with the BANDIT (aside from the native distribution’s package manager) to manage some specific functionality, e.g., the Linux kernel.

The aliens catalog

The aliens catalog is the BANDIT catalog that contains bundles of functionality consisting of third party packages that are not built from source code. These can be closed source packages ranging from video drivers (e.g. NVIDIA display drivers) to full applications (e.g. Visual Studio), or also open source packages but in their binary form (e.g. Amazon Corretto 8 or SAGEMath) so there is no need to build them on the local system.

BANDIT bundles

Unlike other Linux distributions, where the package is the unit of work for their package manager, the BANDIT works with sets of BANDIT items called BANDIT bundles. These bundles items can be packages, but other type of items exist like scripts, and are managed as a logical unit of functionality.

In some sense, a BANDIT bundle recalls the concept of package groups on some other package managers, where a group of related packages are installed or removed all together. However, a BANDIT bundle not only consists of packages but it can also include other type of items like Perl or Python modules or even Bash scripts.

BANDIT systems

In the process of raising a new phySystem, there are three different systems involved with different requirements each. The local system where the raise process starts is the HOST system, and the final, new system is the TARGET system. A temporary, intermediate system, the BUILDER* system, is created but later can be discarded.

Note

The names HOST, BUILDER and TARGET recall those of a cross-compiling environment. Although they are somehow related, their actual meaning in the context of the BANDIT, as well as their intended use are different. Do not get confused if you know about cross-compilation techniques.

These systems need not to be separated physical or virtual machines. The BUILDER system, in fact, consists of the computational resources of the HOST system plus the reserved disk space for the TARGET system.

The TARGET system usually just resides in another disk partition or a directory in the same development HOST system. When desired, the TARGET system disk or partition can be moved to another independent system to boot alone or it can be exported as a container image to be deployed on other machines.

The HOST system

The HOST system is the system where BANDIT is installed and where the BANDIT can manage its software functionality. When acting as a package manager the BANDIT just knows about the localhost as the HOST system,

However, when raising a new distribution, the HOST system is the system used to prepare a clean, new temporary system called the BUILDER that will be used to create the final phySystem, called the TARGET system.

A HOST system can be a working phySystem or any of the supported Linux distributions.

Note

BANDIT has been tested with Debian and Fedora. Other distributions like Arch Linux or Gentoo should work too, as well as derivated distros from Debian or Fedora. For these distros check the building requirements before raising a phy system. See https://docs.phyglos.org/physystem/raiser/requirements.html

The BUILDER system

The BUILDER system is a temporary system created from the HOST system in order to perform the actual, final building of the TARGET system.

This intermediate system is not a truly independent cross-compilation system and is intended to be discarded after the TARGET system is able to run by itself.

Note

Note that in cross-compiling techniques the words host, builder and target are used with different meanings.

The TARGET system

The TARGET system is the final phySystem that, when booted on its own becomes the new phySystem or, when exported and started as a container, runs as an isolated system in the HOST.