Skip to content
Snippets Groups Projects
Commit 25f64346 authored by Martyn Welch's avatar Martyn Welch Committed by Martyn Welch
Browse files

Merge v2019 release artifacts design into images page 


The selection of images as defined for the v2019 release has been used for
a number of releases. This is no longer an open concept, add the
documentation to the images page and remove the concept document.

Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
parent 7f2db982
No related branches found
No related tags found
1 merge request!66Evaluate designs
Hide whitespace changes
Inline Side-by-side
content/architecture/long-term-reproducibility.md
+ 3
− 3
View file @ 25f64346
......@@ -261,9 +261,9 @@ version shipped in the Apertis repositories.
## Main artefacts and metadata
The purpose of the previously described software items is to generate a set of
artefacts, such as those described in [the v2019 release artefacts
document]( {{< ref "release-v2019-artifacts.md" >}} ). With the artefacts themselves a few metadata
entries are generated to help tracking what has been used during the build.
artefacts, such as those described on the [images]( {{< ref "images.md" >}} )
page. With the artefacts themselves a few metadata entries are generated to
help tracking what has been used during the build.
In particular, the `pkglist` files capture the full list of packages installed
on each artefacts along their version. The `filelist` files instead provide
......
content/designs/release-flow.md
+ 2
− 2
View file @ 25f64346
......@@ -456,8 +456,8 @@ documentation will be provided to explain what the scope of each example image
is, which use-cases it validates and which part of the software stack are
fully supported for product usage.
For the 2019 product release this document can be found in the
["Release artifacts for Apertis v2019"]( {{< ref "release-v2019-artifacts.md" >}} ) document.
A description of the expected release artifacts can be found on the
[images]({{< ref "images.md" >}}) page.
## Apertis release flow conclusions
......
content/designs/release-v2019-artifacts.md deleted 100644 → 0
+ 0
− 153
View file @ 7f2db982
+++
title = "Release artifacts for Apertis v2019 [draft]"
short-description = "Draft of the artifacts planned for the Apertis v2019 release"
weight = 100
aliases = [
"/old-designs/latest/release-v2019-artifacts.html",
"/old-designs/v2019/release-v2019-artifacts.html",
"/old-designs/v2020/release-v2019-artifacts.html",
"/old-designs/v2021dev3/release-v2019-artifacts.html",
]
outputs = [ "html", "pdf-in",]
date = "2019-09-27"
+++
# Introduction
This draft document describes which artifacts are expected to be part of the
Apertis v2019 release and what are their goals.
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
* Apt-based images: images meant for development, with a modifiable rootfs that can be customized with the [Apt](https://wiki.debian.org/Apt) package manager
* OSTree-based images: images with a immutable rootfs and a reliable update mechanism based on [OSTree](https://ostree.readthedocs.io/), more similar to what products would use than the Apt-based images
* OSTree repository: server backend used by the OSTree-based images for efficient distribution of updates
* sysroot: rootfs to be used for cross-compilation for platform and application development targeting a specific image
* devroot: rootfs for targeting foreign platforms using binary emulation for platform and application development
* nfs: kernel, initrd, dtb and rootfs tarball for network booting using TFTP and NFS
# Supported platforms
Architectures:
* `amd64`: the common Intel x86 64bit platform, also known as `x86-64`
* `armhf`: the hard-float variant of the ARMv7 32bit platform
* `arm64`: the ARMv8 64bit platform, also known as `aarch64`
[Reference systems]( {{< ref "/reference_hardware/_index.md" >}} ):
* `amd64`: [MinnowBoard Turbot Dual-Core (E3826)]( {{< ref "minnowboard_setup.md" >}} )
* `amd64`: [VirtualBox]( {{< ref "virtualbox.md" >}} ) for the SDK virtual machines
* `armhf`: [i.MX6 Sabrelite]( {{< ref "imx6q_sabrelite_setup.md" >}} )
* `arm64`: [Renesas R-Car M3 Starter Kit Pro (M3SK/m3ulcb)]( {{< ref "rcar-gen3_setup.md" >}} )
# Supported artifacts
This is an overview of the release artifacts:
* `minimal` ospacks
* amd64, armhf, arm64
* OSTree repository
* Apt-based and OSTree-based system images for the reference hardware platforms
* `target` ospacks
* amd64, armhf, arm64
* OSTree repository
* Apt-based and OSTree-based system images for the reference hardware platforms
* `basesdk` ospacks
* amd64
* Apt-based system image for VirtualBox
* `sdk` ospacks
* amd64
* Apt-based system image for VirtualBox
* `sysroot` ospack
* amd64, armhf, arm64
* tarball matching the target ospack
* `devroot` ospack
* amd64, armhf, arm64
* tarball
* `nfs` ospack
* amd64, armhf, arm64
* tarball and unpacked kernel artifacts for TFTP/NFS network booting
## Minimal
Minimal 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 succesfully boot on the reference
hardware, the minimal example images ship the complete connectivity stack.
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 `minimal` ospacks and images.
## Target
Target images provide the most complete superset of the features offered by the minimal 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 `target` ospacks and images.
The release also includes sysroots which include development tools, headers,
and debug symbols for all the components shipped on target images. These
sysroots contains software covered by the GPLv3 as they are meant for
development purposes only.
## Base SDK
The base SDK images are 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 using the Canterbury application
framework and the Mildenhall HMI.
## Sysroot
Sysroots are 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.
## Devroot
Devroots are 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.
For more informations about using devroots see the
["Programming guidelines" section](https://developer.apertis.org/latest/programming-guide-tooling.html#development-containers-using-devrootenter).
## 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
content/policies/images.md
+ 118
− 19
View file @ 25f64346
+++
date = "2019-10-25"
date = "2020-09-02"
weight = 100
title = "Images"
aliases = [
"/old-wiki/Images"
"/old-wiki/Images",
"/old-designs/latest/release-v2019-artifacts.html",
"/old-designs/v2019/release-v2019-artifacts.html",
"/old-designs/v2020/release-v2019-artifacts.html",
"/old-designs/v2021dev3/release-v2019-artifacts.html",
]
+++
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 also has a daily set of images
followed by a stable release. Apertis also has a daily set of artifacts
which can be used for the latest testing.
You can find:
You can find them here:
- [stable release images](https://images.apertis.org/release/)
- [daily build images](https://images.apertis.org/daily/)
- [stable release artifacts](https://images.apertis.org/release/)
- [daily build artifacts](https://images.apertis.org/daily/)
- [ostree repository](https://images.apertis.org/ostree/repo/)
Apertis is actively developed, so you should always develop against
either the latest release or the daily build images.
There are five types of images available, depending on the platform:
For the supported platforms, see
[Reference Hardware]( {{< ref "/reference_hardware/_index.md" >}} ).
- **minimal**: headless systems
- **target**: systems with graphical stack and basic HMI
- **basesdk**: full desktop environment to develop for Apertis, meant
to be run under [VirtualBox]( {{< ref "/virtualbox.md" >}} )
- **sdk**: full desktop environment to develop for Apertis with extra
tools to write Canterbury and Mildenhall apps, meant to be run under
[VirtualBox]( {{< ref "/virtualbox.md" >}} )
The main kinds of artifacts are:
The supported platform are (see [Reference
Hardware]( {{< ref "/reference_hardware/_index.md" >}} )):
* **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
* **Apt-based images**: images meant for development, with a modifiable rootfs that can be customized with the [Apt](https://wiki.debian.org/Apt) package manager
* **OSTree-based images**: images with a immutable rootfs and a reliable update mechanism based on [OSTree](https://ostree.readthedocs.io/), more similar to what products would use than the Apt-based images
* **OSTree repository**: server backend used by the OSTree-based images for efficient distribution of updates
- **amd64**: Intel 64bit (using UEFI)
- **armhf**: ARM 32bit (using u-boot)
- **arm64**: ARM 64bit (using u-boot)
# Image Types
There are a number of types of images provided by Apertis, depending on the
platform, including:
## Minimal
Minimal 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 succesfully boot on the reference
hardware, the minimal example images ship the complete connectivity stack.
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 `minimal` ospacks and images.
## Target
Target images provide the most complete superset of the features offered by the
minimal 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 `target` ospacks and images.
## Base SDK
The base SDK images are APT-based and meant to be run as
[VirtualBox]( {{< ref "/virtualbox.md" >}} ) 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 using the Canterbury application
framework and the Mildenhall HMI.
## 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.
## 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.
For more informations about using devroots see the
["Programming guidelines" section](https://developer.apertis.org/latest/programming-guide-tooling.html#development-containers-using-devrootenter).
## 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:
| Type | amd64 | armhf | arm64 | APT | OSTree |
| ---------- | ----- | ----- | ----- | --- | ------ |
| Minimal | ✅ | ✅ | ✅ | ✅ | ✅ |
| Target | ✅ | ✅ | ✅ | ✅ | ✅ |
| Base SDK | ✅ | | | ✅ | |
| SDK | ✅ | | | ✅ | |
| Sysroot | ✅ | ✅ | ✅ | | |
| Devroot | ✅ | ✅ | ✅ | ✅ | |
| NFS | ✅ | ✅ | ✅ | ✅ | |
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
Apertis Website Terms of Use Privacy Policy