In the past, there have been multiple requests and use cases for updating the application or data files (referred to as 'artifacts' in the future) without the need to update the rootfs.
So, far there is no ready-to-use concept for this since RAUC bundles are designed to define the entire target state of the system (and handled as such).

Since the rootfs should still be defined by the image contained in the bundle, RAUC should not simple write the artifacts into the rootfs.
Artifacts will be written into a separate slot (partition) only. For an alternative to modifying files in the rootfs, see further down.

From our perspective, there are two types of artifacts that must be handled differently:

• artifacts without dependencies into the rootfs: typically container, or data files (e.g. navigation maps)
• artifacts with dependencies into the rootfs: typically applications built against system libraries

For the first case (no dependency) there can be a single artifact partition for all rootfs partitions.
This makes handling (like mounting) easy.

For the second case (with dependencies) there should be an artifact partition for each rootfs partition.
So that when falling back, application and libraries still match.

A partition should hold one or many artifacts that each can be updated individually and, as other updates done with RAUC, artifact updates also need to be atomic.

To achieve this, RAUC must not create or format the file system of the artifact partition. For updating the artifacts inside this file systems, different techniques can apply, depending on the type of artifact (data):

• single files: can be updated atomically with copy&rename
• directory trees: can be updated atomically with ostree or copy&rename
• docker container: can be updated with 'docker import' from the bundle artifact

For the above-mentioned use case of overriding files in the rootfs, two possible solutions exist:

• bind mount the file to the file in the artifact partition
• use directory from artifact partition as seed for an overlayfs

The syntax could look as follows:

system.conf:

[slot.rootfs.0]
device=/dev/sda1
type=ext4

[slot.rootfs.1]
device=/dev/sda2
type=ext4

[slot.myartifacts]
device=/dev/sda3
type=artifacts

manifest:

[image.myartifacts]
filename=app1.docker
filename=app2.run

An alternative could be to define a slot for each artifact. Naming this artifacts is just an initial proposal.

This is just a draft concept. Comments and opinions are welcome.