Table of Contents:

Apertis has a release lifecycle which is roughly three months long. Each release consists of a round of development, testing and bug fixing, followed by a stable release.

Apertis provides images from daily build artifacts through to historic releases (which have reached their end of life) for supported platforms. This allows users and developers to both look at the latest changes as well as look at the historic state, which can be useful when testing just merged fixes and tracking down the origin of a bug respectively. The various available images can be found on the Apertis image site.

The main kinds of artifacts are:

• ospack: Rootfs without the basic hardware-specific components like bootloader, kernel and hardware-specific support libraries
• system image: combines an ospack with hardware-specific components in a snapshot that can be directly deployed on the supported boards
  • OSTree-based images: images with a immutable rootfs and a reliable update mechanism based on OSTree, more similar to what products would use than the Apt-based images
  • Apt-based images: images meant for development, with a modifiable rootfs that can be customized with the Apt package manager
• OSTree repository: server backend used by the OSTree-based images for efficient distribution of updates

Image Types

There are a number of types of images provided by Apertis, depending on the platform, including:

FixedFunction

FixedFunction images provide compact example images for headless systems and are a good starting point for product-specific customizations.

Other than basic platform support in order to successfully boot on the reference hardware, the FixedFunction example images ship the complete connectivity stack serving a minimal static web page.

The reference update system is based on OSTree, but APT-based images are also provided for development purposes.

No artifact covered by the GPLv3 is part of the fixedfunction ospacks and images.

HMI

HMI images provide the most complete superset of the features offered by the FixedFunction images, shipping full graphics support with a sample HMI running on top and applications with full multimedia capabilities.

The reference update system is based on OSTree, but APT-based images are also provided for development purposes.

No artifact covered by the GPLv3 is part of the core hmi ospacks and images. Images and ospacks available for download from our website do, however, include GPLv3 Flatpak runtimes and applications for demonstration purpose. Those can easily be uninstalled and/or excluded from custom-built images.

Base SDK

The base SDK images are APT-based and meant to be run as VirtualBox VMs to provide a standardized, ready-to-use environment for developers targeting Apertis, both for platform and application development.

Since the SDK images are meant for development, they also ship tools covered by the GPLv3 license.

SDK

The full SDK images provide the same features as the base SDK images with additional tools for application development.

Sysroot

Sysroots are archived filesystem trees specifically meant for cross-compilation and remote debugging targeting a specific release image.

They are meant to be read-only and target a specific release image, shipping all the development headers and debug symbols for the libraries in the release image.

Sysroots can be used to cross-compile for Apertis from a third-party environment using an appropriate cross-toolchain. They are most suited for early development phases where developers focus on quick iterations and rely on fast incremental builds of their components.

The sysroots contain software covered by the GPLv3 as they are meant for development purposes only.

See sysroots amd devroots for more information about sysroots.

Devroot

Devroots are archived filesystem trees meant to offer a foreign architecture build environment via containers and binary emulation via the QEMU user mode.

They ship a minimal set of packages and offer the ability to install all the packages in the Apertis archive.

Due to the nature of foreign architecture emulation they impose a considerable overhead on build times compared to sysroot, but they avoid all the intricacies that cross-building involves and offer the ability to reliably build deb packages targeting foreign architectures.

See sysroots amd devroots for more information about when to use devroots. For more informations about using devroots see the tooling documentation.

NFS

The release includes artifacts for network booting using the TFTP and NFS protocols:

• kernel images for the reference architectures to be loaded via TFTP
• initrd with kernel modules matching the image to be loaded via TFTP
• DTBs (compiled device trees) for the reference hardware platforms to be loaded via TFTP
• rootfs tarball to be loaded via NFS

Supported Artifacts

Here’s a basic overview of the architectures and update mechanisms supported by each image type:

* Since v2020