A long time ago we changed rpm-ostree to default to adding composefs metadata. I hadn't noticed at the time how expensive that is if the build system doesn't have verity enabled which is going to be the common case, which is its own issue. But build time performance here isn't as relevant as client side, and the semantics.
In the original version of that patch that broke checkout --composefs in the !verity case when we have an expected digest in the commit (as every rpm-ostree generated commit will have).
Obviously bigger picture we have a mess here because the bootc based testing isn't using this flow as it's doing a client side commit and deployment from that.
In the immediate short term I think I want to back out adding the composefs metadata to rpm-ostree by default, but that's a different thing.
On the ostree side here I think we should just stop checking the generated composefs when we're !verity because there's no integrity here.
I'm thinking we should never do "add fsverity if it exists" into the composefs as that previous PR was doing; either it's enabled or it's not, and half-measures are broken.
A long time ago we changed rpm-ostree to default to adding composefs metadata. I hadn't noticed at the time how expensive that is if the build system doesn't have verity enabled which is going to be the common case, which is its own issue. But build time performance here isn't as relevant as client side, and the semantics.
In https://github.com/ostreedev/ostree/pull/3326 I changed things so we only add the verity digest in the generated composefs if we have it.
In the original version of that patch that broke
checkout --composefsin the !verity case when we have an expected digest in the commit (as every rpm-ostree generated commit will have).Obviously bigger picture we have a mess here because the bootc based testing isn't using this flow as it's doing a client side commit and deployment from that.
In the immediate short term I think I want to back out adding the composefs metadata to rpm-ostree by default, but that's a different thing.
On the ostree side here I think we should just stop checking the generated composefs when we're !verity because there's no integrity here.
I'm thinking we should never do "add fsverity if it exists" into the composefs as that previous PR was doing; either it's enabled or it's not, and half-measures are broken.