To resolve the use cases presented, we first define a master process. This master process has been left intentionally abstract and has to be specialised to suit each use case. Because of this, we have refined a solution for each of the use cases from the master process. Thus, we have three processes: Process for creating a new distribution, process for updating a distribution and process for creating a new release of a distribution. Each of the refined processes is a complete set of actions required for fulfilling the use case.
These kind of processes are not new though. For example, Fedora has been using a similar process for a long time, at least seven years. The implementation of that process is the Koji tool, first created in 2010. For our purposes we would like to have something similar. The Fedora model is quite appealing as it has been in use for a long time and has been tried and tested.
5.3.1 Master process for creating and maintaining a distribution
This process illustrates the general overview on how each of the following, refined processes work. This ”process” is more to show the very high level ideas that each of the processes have. All the other processes have been refined from this process. This process is not used in any of the proof of concept tests. This process can also be thought of as the framework process. We present this process to show our thought pattern and to record how we came up with the processes we used in our proof of concept project. Three use cases have been refined from this process.
1. Create a set of packages. In this step we create a set of binary packages. This step requires source code and configuration files and outputs the packages.
2. Store the previous steps inputs and outputs. In this step we place the created packages and the inputs into repositories. This step takes as input the outputs
and inputs of the previous step and store them into a repository.
3. Use packages and build system configuration to create or recreate a distri- bution. We use the repositories created in the previous step and some build system configurations to output a Linux distribution image. This step takes as input the build system configuration. In these configurations the used pack- ages and possibly the repositories of these packages are specified. This step outputs a new distribution image.
5.3.2 Process for creating new operating system distributions and their images
This is a process for creating a brand new distribution from source packages and configurations. This process should be relatively rare as it would be required only if there are no existing distribution repositories. This creation process requires the source code for all the packages about to be included in the new distribution. In addition, some location is required for the different repositories. The configurations for the packages and the image need to be created or acquired.
1. Acquire source code and acquire or create package configurations for all pack- ages.
2. Using the source code and configurations, create binary packages.
3. Store the newly made binary packages into a repository, the source code into another repository and the configurations into a third repository.
4. Create a new configuration for a build system.
5. Store this build system configuration into a repository.
6. Use a build system to build a new distribution from the stored binary packages and the build system configuration.
5.3.3 Process for maintaining existing packages of a distribution
In this process, we are updating some packages of a distribution. If most of the packages of a distribution would be upgraded, then a new release should be made instead of a simple update operation. This update process requires the sources of the
packages being updated. Also, no additional repositories should be needed as the inputs (sources and configurations) and outputs (binary packages and distribution images) should already have some repository where to update the respective items into. This is due to
1. For all the packages involved in the maintenance, modify configurations if necessary and apply updated sources.
2. Using the updated sources and configurations, recreate updated binary pack- ages.
3. Add the new versions of the binary packages to the same repository as the old ones keeping the old versions. Do the same with sources and configurations with their respective repositories.
4. Modify the build system configuration, if necessary.
5. Store the updated build system configuration in a repository.
6. Using the updated binary repository and build system configuration recreate the distribution.
5.3.4 Process for creating a new release of a distribution
This process includes steps similar to the two earlier processes. This process would be used when there are enough updates to many packages that the distribution would be considered a new distribution. At this point a new release should be made instead of just continuously updating the packages. However, this new release is still likely to contain packages found in a earlier release of this distribution meaning that we wouldn’t be starting totally from nothing.
1. Create new repositories for binary and source packages, package configura- tions and build system configurations. These repositories should be named according to the new release version.
2. Fill these new repositories with desired packages and configurations accord- ingly.
3. If necessary, recreate binary packages using sources and package configurations and add the recreated binary packages to their correct repository
4. Modify the build system configuration, if necessary.
5. Store the updated build system configuration in build system configuration repository.
6. Using this new binary repository and new build system configuration, create a new distribution using the build system of choice.