A toplevel goal of this project is to not fork the underlying OS. Contrast with e.g. https://github.com/coreos/fedora-coreos-config/ which carries its own lockfiles, which creates divergence.
Today, the fedora-derivatives tooling uses "composes" which are basically versioned directories written to NFS-like storage and served by HTTP with custom JSON metadata.
It'd be useful for us to have our version number (which is reflected both in /usr/lib/os-release and the standard org.opencontainers.image.version label) include the underlying compose version.
rpm-ostree supports a mutate-os-release key which is intended for this. I think what may work best is if we have a new yaml file like:
$ cat versioning.yaml
variables:
composeversion: "20240113.d.0"
automatic-version-prefix: "${releasever}.${composeversion}"
or so? Then we'd need to overwrite composeversion.yaml in git too. Hmm, maybe we don't need ${releasver} here at all. Yeah...let's just simplify this to:
variables:
composeversion: "20240113.d.0"
automatic-version-prefix: "${composeversion}"
A toplevel goal of this project is to not fork the underlying OS. Contrast with e.g. https://github.com/coreos/fedora-coreos-config/ which carries its own lockfiles, which creates divergence.
Today, the fedora-derivatives tooling uses "composes" which are basically versioned directories written to NFS-like storage and served by HTTP with custom JSON metadata.
It'd be useful for us to have our version number (which is reflected both in
/usr/lib/os-releaseand the standardorg.opencontainers.image.versionlabel) include the underlying compose version.rpm-ostree supports a
mutate-os-releasekey which is intended for this. I think what may work best is if we have a new yaml file like:or so? Then we'd need to overwrite composeversion.yaml in git too. Hmm, maybe we don't need
${releasver}here at all. Yeah...let's just simplify this to: