commit: Always enable generation of composefs metadata if possible

[alexlarsson]

There is no particular cost to always adding composefs metadata to rpm-ostree composes, so always do so if libostree is new enough and has the support compiled in.

[openshift-ci]

Hi @alexlarsson. Thanks for your PR.

I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[alexlarsson]

Got this failure in "CI / Container build (pull_request) ":

rpm-ostree: /lib64/libostree-1.so.1: version `LIBOSTREE_2023.4' not found (required by rpm-ostree)
Error: error building at STEP "RUN cd /etc/yum.repos.d/ && curl -LO https://pkgs.tailscale.com/stable/fedora/tailscale.repo &&     rpm-ostree install tailscale &&     systemctl enable tailscaled &&     ostree container commit": error while running runtime: exit status 1

Are we mixing ostree versions used during build and at runtime?

[cgwalters]

Are we mixing ostree versions used during build and at runtime?

Yes, in this job. It will be a little annoying to fix. If we wait a little bit until the new ostree hits fcos stable, the issue will go away on its own.

[alexlarsson]

What is the status of this? Did the new ostree hit fcos?

[cgwalters]

What is the status of this? Did the new ostree hit fcos?

$ podman run --pull=newer --rm -ti quay.io/fedora/fedora-coreos:stable rpm -q ostree
ostree-2023.4-2.fc38.x86_64

So yes

[cgwalters]

/ok-to-test