Blog

On December 3, 2021, we integrated the EuroLinux development pipelines with automatic source synchronization on the public WWW. From now on, the system sources are publicly available in Source RPM format. While maintaining licensing requirements, we can involve the community even more in rebuilding and gaining experience with the system. In contrast to some vendors (including “community” distributions), we provide complete sources in an easy way. Also those that are used only as dependencies of the modular build (they are not available in the final version of the system).

The Vault project also has a second function – maintaining older versions. It allows slimming down the current version of the main repository, where for example, there are seven versions of Firefox. Following the policy known from previous versions of EuroLinux and other distributions, from now on, we keep three versions of packages (the current one and two older ones) on the servers. This policy allows faster repository creation and saves space for mirroring organizations.

More on how we decided to make Vault available along with additional contexts is available below.

Why do we share sources in src.rpm instead of in a version control system (such as Git)?

Below are the results of our analysis of the feasibility of sharing sources in Git code repositories and as src.rpm files.

Challenges of maintaining all sources in a version control system:

• many sources contain binary files
• version control systems do not deal well with large binary objects (BLOB – Binary Large Object [this is a generic term that means precompiled code in specific cases]) such as tar.gz archives, ISO files or even larger png images
• the solution to the BLOB problem may be using version control systems that natively support it. For example, computer game developers often use Perforce because it is much better at supporting “assets” (such as textures and binary files). However, Perforce is a system that is not widely known, and its license is closed and requires fees
• if we preferred staying with Git, we could unpack the sources using helper scripts. However, this technique requires additional work from the end-user. On top of that, it generates one problem – the original sources can be downloaded from the project pages and their checksums will check. Sources re-packaged with helper scripts may have different checksums
• the possible use of Git LFS (Git Large File System) is unintuitive for many users. On top of that, it requires additional integrations
• current Git LFS offerings are relatively expensive. Observing the download statistics of the EuroLinux sources made available to several organizations, when rebuilding version 8.5 using Gaia, the viability of Git LFS came into question. The increased traffic from the community (for which we are very thankful) and our overall growth (as an organization) would generate high additional costs. We believe it is more efficient to redirect resources to hiring more engineers and having a cheaper and easier to maintain solution (we write about the advantages of providing sources as src.rpm later)
• another solution to the BLOB problem, known, e.g. from Fedora or CentOS distributions, is to keep some sources available in the version control service and some in git lookaside (a web service serving compressed sources). However, this is not very intuitive. On top of that, it is more of a developer solution, made for centralized build systems like Koji. Our proprietary EuroLinux Gaia system is decentralized. The only central point is the Git repository of the configuration (decentralizing this repository is trivial – after all, we are talking about a project maintained in Git). The next generation of Gaia (Work in Progress) with the new projects we are working on is also expected to maintain this key feature (decentralization).

Advantages of providing sources as Source RPM files (src.rpm):

• src.rpm sources are signed with GPG key – the same key which EuroLinux packages are signed with
• administrators or developers can quickly find the package they are looking for
• no need to know new specialized tools
• scaling is as trivial as adding new hosts or using an external CDN system
• maintaining this solution is easy
• links to the source repository can easily be added to the `el-release` package
• local mirroring is trivial
• the solution integrates into existing CI/CD scripts in a convenient way.

Considering the advantages and disadvantages, we decided to make the sources available as src.rpm. Finally, it should be noted that many sources will still be available in parallel both in the version control system and in the src.rpm files made available after the packages are built.

EuroLinux 8.4 available in Vault

EuroLinux 8.4 is the first version of the system to be made available in Vault. Archiving older versions makes it possible, among other things, to create packages for the current version of the system in exceptional situations. Unfortunately, not all packages are massively rebuilt and updated by Red Hat^® when a new minor version is released. Mass rebuilding of packages for newer versions was introduced, among others, by Fedora. The lack of such a policy means that changing or updating some libraries to the latest versions, in rare cases, would not allow a package to be built.

Importantly for some users, Vault also allows you to migrate, for example, from Red Hat^® Enterprise Linux^® 8.4 to EuroLinux 8.4 without upgrading a minor version.

We will also be putting older versions of other artifacts into Vault in the near future.

Another item on the roadmap accomplished

Making the Vault service available was one of the points on the EuroLinux roadmap. We will be completing most of them in the near future. Thank you for your interest in our solutions.

The roadmap is described in detail in this article.