Any system that is part of the build/distribution infrastructure can be classified as one of the following types of systems.

A bootstrap server is a server that is used to bootstrap a new build of Cucumber Linux from Scratch; it is the system doing the initial build, through the end of phase 4.

1. Build the initial Cucumber Linux from Scratch build.
2. Create the initial CHANGELOG, contents.bz2, file-list and updates files.
3. Upload the initial ports tree and package directories and CHANGELOG, contents.bz2, file-list and updates files to the staging server.
4. Build the initial installation ISO images.

A build server is a server that is used to build updated packages for an existing build of Cucumber Linux. Each Build Server has a staging server that it works with; the build server is responsible for building the updated packages and then uploading them to the appropriate directory on the staging server.

1. Build updated packages.
2. Determine the appropriate package tarball name for each package built.
3. Move old packages to the old_packages directory.
4. Pull its /usr/ports directory down from its staging server.
5. Push its /opt/packages and /opt/old_packages directories up to its staging server.
6. Build any ISO updated images that are not the initial ISO image for a build of Cucumber Linux.

A distribution server is essentially a mirror server; it holds the binary packages, source code, installer and ports tree for a set of Cucumber Linux versions. The set of versions to mirror may contain one or more versions of Cucumber Linux.

1. Provide a publicly facing mirror server the Cucumber Linux packages, source code and installer.

A staging server is basically a special distribution server where changes are initially uploaded for testing. All systems that are testing new changes to ensure they are stable use a staging server as their mirror instead of a distribution server. Once the changes on the staging server are deemed to be ready for general release, they are “pushed” out to all of the distribution servers that the staging server is responsible for updating; these distribution servers are known as “associated distribution servers”. A staging server can be responsible for updating one or more distribution servers. A staging server stages exactly one version of Cucumber Linux for testing.

1. Push appropriate updates out to all of its associated distribution servers.
2. Update the CHANGELOG, contents.bz2, file-list and updates files as necessary.

There are a few special files on the staging and distribution servers. These are their purposes. Substitute the target architecture in for ARCH.

The CHANGELOG file contains a list of changes to the binary packages contains a list of changes to the binary packages for a specific architecture, along with a brief explanation of each change. Security fixes are tagged as such by putting a line containing * SECURITY FIX * at the end of the entry.

The CHANGELOG file used to be located at the root of the cucumber-x.y directory. It also used to track source changes as well as binary changes. In Cucumber Linux 2.0, this changed. The source code was migrated to Git, and Git commits became the primary method for tracking source code changes. This rendered the CHANGELOG file necessary only for tracking the binary changes. Since, with this change, the CHANGELOG became exclusively architecture specific, it made more sense to split it into separate files: one for each architecture.

This file contains a list of all the files contained in each binary package for the entire distribution. Note that this is a lot of files, which results in the contents file being quite large, hence why it is bzipped. It is used by pickle when running pickle –file-search.

This file contains a list of all the package files (*.txz files) located under the cucumber-ARCH directory. It is used by pickle for determining available packages.

This file contains a list of updates to the binary packages. It is used by pickle when determining the available updates.