rpm-ostree/docs/extensions.md
Jonathan Lebon 271954a41c app: Add rpm-ostree compose extensions
This adds support for a new `rpm-ostree compose extensions` command`
which takes a treefile, a new extensions YAML file, and an OSTree repo
and ref. It performs a depsolve and downloads the extensions to a
provided output directory.

This is intended to replace cosa's `download-extensions`:
https://github.com/coreos/coreos-assembler/blob/master/src/download-extensions

The input YAML schema matches the one accepted by that script.

Some differences from the script:
- We have a guaranteed depsolve match and thus can avoid silly issues
  we've hit in RHCOS (like downloading the wrong `libprotobuf` for
  `usbguard` -- rhbz#1889694).
- We seamlessly re-use the same repos defined in the treefile, whereas
  the cosa script uses `reposdir=$dir` which doesn't have the same
  semantics (repo enablement is in that case purely based on the
  `enabled` flag in those repos, which may be different than what the
  rpm-ostree compose ran with).
- We perform more sanity-checks against the requested extensions, such
  as whether the extension is already in the base.
- We support no-change detection via a state SHA512 file for better
  integration in cosa and pipelines.
- We support a `match-base-evr` key, which forces the extension to have
  the same EVR as the one from a base package: this is helpful in the
  case of extensions which complement a base package, esp. those which
  may not have strong enough reldeps to enforce matching EVRs by
  depsolve alone (`kernel-headers` is an example of this).
- We don't try to organize the RPMs into separate directories by
  extension because IMO it's not at the right level. Instead, we should
  work towards higher-level metadata to represent extensions (see
  https://github.com/openshift/os/issues/409 which is related to this).

Closes: #2055
2021-01-23 17:12:09 +01:00

57 lines
1.8 KiB
Markdown

---
nav_order: 6
---
# Extensions
Extensions are additional packages which client machines can
install using package layering. While rpm-ostree itself is
indifferent on the subject, most rpm-ostree-based distros
encourage a containerized workflow for better separation of
host and application layers. But sometimes, containerization
is not ideal for some software, and yet it may not be
desirable to bake them into the OSTree commit by default.
Package layering normally fetches such extensions from
remote repos. However in some architectures there may be a
better way to transfer them, or one may simply want tighter
control over them and stronger binding between OSTree commit
and extension versions (e.g. for reproducibility, guaranteed
depsolve, QE, releng, etc..).
`rpm-ostree compose extensions` takes an `extensions.yaml`
file describing OS extensions (packages) and a base OSTree
commit. After performing a depsolve, it downloads the
extension packages and places them in an output directory.
## extensions.yaml
The format of the `extensions.yaml` file is as follow:
```yaml
# The top-level object is a dict. The only supported key
# right now is `extensions`, which is a dict of extension
# names to extension objects.
extensions:
# This can be whatever name you'd like. The name itself
# isn't used by rpm-ostree.
sooper-dooper-tracers:
# List of packages for this extension
packages:
- strace
- ltrace
# Optional list of architectures on which this extension
# is valid. These are RPM basearches. If omitted,
# defaults to all architectures.
architectures:
- x86_64
- aarch64
kernel-dev:
packages:
- kernel-devel
- kernel-headers
# Optional name of a base package used to constrain the
# EVR of all the packages in this extension.
match-base-evr: kernel
```