Managing build infrastructure of a Debian derivative

Apertis is a Debian derivative tailored to the automotive needs and fit for a wide variety of electronic devices. Security and modularity are two of its primary strengths. Apertis provides a feature-rich framework for add-on software and resilient upgrade capabilities. Beyond an operating system, it offers new APIs, tools and cloud services.

Apertis provides code hosting, code review tools, package build and image generation services, and an automated testing infrastructure with aim of providing a clean, reliable environment to let developers go from sources to deployable system images in the most dependable way. It aims to be the integration point for different product lines with different goals and different schedules, but all sharing the same common core.

Apertis is based on Ubuntu and Debian, taking most of the system from Ubuntu, several packages directly from Debian, and provides its own software packages, frameworks, APIs etc.

Apertis makes heavy use of some technologies for its purposes:

• Ubuntu/Debian packages
• systemd for application lifecycle tracking
• AppArmor for policy enforcement
• D-Bus for IPC and privilege separation
• Wayland for graphics
• GStreamer for multimedia playback
• OSTree/Flatpak for safe and efficient deployments

Apertis uses OSTree to provide an upgrade mechanism for the base OS (where updates are critical). The applications (where updates are less critical and more frequent) are distributed in a format based on Flatpak (which itself uses OSTree bundles).

This OSTree-based update system replaces an earlier solution based on btrfs. The btrfs-based updater required significant maintenance effort, couldn’t be used for all partitions, since bootloader didn’t support btrfs, required initramfs, directly manipulated btrfs volumes, making it not possible to use it in non-privileged containers, and also had all issues of btrfs itself, of which there are many. In comparison, OSTree works with any filesystem, can store multiple trees in the same repository, doesn’t need extra partitions for safe upgrades, and works better with containers. Apart from that, it’s a full solution on its own, not just a building block or a tool, so using it reduces the maintenance burden, since there’s much less custom code.