Treefile

A "treefile" is a made up term for a JSON-formatted specification used as input to rpm-ostree compose tree to bind "set of RPMs with configuration" to "OSTree commit".

It's recommended to keep them in git, and set up a CI system like Jenkins to operate on them as it changes.

It supports the following parameters:

An example use case for this is for Fedora CoreOS, which will blacklist the python and python3 packages to ensure that nothing included in the OS starts depending on it in the future.

Each array element is an array, whose first member is a package name, and subsequent members are regular expressions (compatible with JavaScript).

Example: remove-from-packages: [["cpio", "/usr/share/.*"], ["dhclient", "/usr/lib/.*", "/usr/share/.*"]]

Note this does not alter the RPM database, so rpm -V will complain.

Example: check-passwd: { "type": "none" } Example: check-passwd: { "type": "previous" } Example: check-passwd: { "type": "file", "filename": "local-passwd" } Example: check-passwd: { "type": "data", "entries": { "bin": 1, "adm": [3, 4] } } See also: ignore-remove-users

Example: check-groups: { "type": "none" } Example: check-groups: { "type": "previous" } Example: check-groups: { "type": "file", "filename": "local-group" } Example: check-groups: { "type": "data", "entries": { "bin": 1, "adm": 4 } } See also: ignore-remove-groups

Example: ignore-removed-users: ["avahi-autoipd", "tss"]

Example: ignore-removed-groups: ["avahi"]

Example: releasever: "26"

A current date/time may also be passed through automatic-version-prefix, by including a date tag in the prefix as such: <date:format>, where format is a string with date formats such as %Y (year), %m (month), etc. The full list of supported formats is found in the GLib API. Including a date/time format will automatically append a .0 to the version, if not present in the prefix, which resets to .0 if the date (or prefix) changes.

This means that on an empty branch with an automatic-version-prefix of "22" the first three commits would get the versions: "22", "22.1", "22.2". Some example progressions are shown:

automatic-version-prefix version progression
22 22, 22.1, 22.2, ...
22.1 22.1.1, 22.1.2, 22.1.3, ...
22.<date:%Y> 22.2019.0, 22.2019.1, 22.2020.0, ...
22.<date:%Y>.1 22.2019.1.0, 22.2019.1.1, 22.2020.1.0, ...

Example: automatic-version-prefix: "22.0"

It is strongly recommended to avoid using this except as a last resort. Having the system generated through RPMs allows administrators to understand the inputs to the system. Any new files created through this mechanism will not have the versioning inherent in RPM.

Only the script file will be copied in; thus if it has any dependencies, on data beyond what is in the target tree, you must embed them in the binary itself.

An example use for this is working around bugs in the input RPMs that are hard to fix in stable releases.

Note this does not alter the RPM database, so rpm -V will complain.

If you want to depend on network access, or tools not in the target host, you can use the split-up rpm-ostree compose install and rpm-ostree compose postprocess/commit commands.

Example (in YAML):

yaml arch-include: x86_64: bootloader-x86_64.yaml s390x: - bootloader-s390x.yaml - tweaks-s390x.yaml

Each array element is an array, whose first member is the source file name, and the second element is the destination name. The source file must be in the same directory as the treefile.

Example: "add-files": [["bar", "/usr/share/bar"], ["foo", "/lib/foo"]]

Note that in the OSTree model, not all directories are managed by OSTree. In short, only files in /usr (or UsrMove symlinks into /usr) and /etc are supported. For more details, see the OSTree manual: https://ostree.readthedocs.io/en/latest/manual/deployment/

Experimental options

All options listed here are subject to change or removal in a future version of rpm-ostree.