StarlingX/Developer Guide/Build System

StarlingX Mirror
One of the features of StarlingX is to provide an ISO image ready to be installed in a deployment. This offers to the user a simple way to get everything configured and ready to use after installation. To get this done, StarlingX uses packages from upstream CentOS to provide a curated GNU/Linux distribution.

Four type of items are used by the StarlingX build system to create the ISO image:
 * RPMs : These are runtime or build dependencies for the system. Some of these packages are included in the ISO and other are just used for building.
 * Source RPMs : This is the source code of projects that are modified or extended by StarlingX. The build system will use these packages to create a new set of source rpms with patches applied to generate the final rpms.
 * Tarballs : Some componentes requires specific software that is not possible to find in a CentOS repository. The tarballs are used to generate source rpms with patches applied by StarlingX.
 * Binaries : These are files like `squashfs.img` or `initrd.img` used to create the ISO. The build system will modify the CentOS boot files to form the final ISO image.

In order to build StarlingX it is required to have all these files in place. To simplify this process a tool to download all these dependencies was created, however as upstream CentOS constantly changes is common to have issues downloading all the packages. This document tries to explain the process of downloading a mirror, verify that is correct and troubleshoot when is necessary.

Designer
The 'designer' disk is for sourcecode.

Loadbuild
The 'loadbuild' disk is for the build environment and the generated rpms and iso.

Build

 * build-pkgs-serial
 * build-pkgs-parallel
 * std build
 * rt build
 * installer build
 * build-srpms-serial
 * build-rpms-serial
 * build-srpms-parallel
 * build-rpms-parallel

Mock
For serial build use:

For parallel build use:

Enter your mock

Build ISO
http://lists.starlingx.io/pipermail/starlingx-discuss/2018-August/000745.html

To Be Assigned
http://lists.starlingx.io/pipermail/starlingx-discuss/2018-July/000486.html

It is awesome!! Running “create_dependancy_cache.py” against the mirror (of RPMs) is to generate a new “dependancy-cache”, isn’t it? I had a successful parallel build (aka build-pkgs --parallel) inside the docker container. ~1h45m on 24 core, 64G ram The prerequisite was a populated $MY_REPO/cgcs-tis-repo/dependancy-cache Currently we only generate the cache after the build in the 'generate-cgcs-tis-repo' step. I'd like to see the cache stored in git and updated regularly by 'official' builds. Note: The cache doesn't have to be perfect, so a cache that is out of date by a day or a week is still very useful. build-pkgs/mockchain just needs a rough guide on build dependencies and potential dependency loops.