Add a bootc.diskimage-builder label

[cgwalters]

Right now, the relationship between this image and bootc-image-builder is "floating". However, we may want the ability to more strictly bind the two in the future.

With this, the bootc image links out to the recommended diskimage builder container, so automated tooling can find it instead of hardcoding it.

[cgwalters]

To be explicit a goal of this is that things like https://github.com/containers/podman-desktop-extension-bootc/blob/c15e40664f11728b8c95eb8213573e0c8af8f8d8/packages/backend/src/constants.ts#L21 go away in favor of inspecting the input bootc image.

(The hardcoded version there is a distinct thing of course)

[deboer-tim]

With this, the bootc image links out to the recommended diskimage builder container, so automated tooling can find it instead of hardcoding it.

What's the reasoning behind this, or when would it point to anything different? I'm not aware of any other image builders and if it had a tag here it would be like the equivalent of a container image saying which version of Podman it runs on.

To be clear, https://github.com/containers/podman-desktop-extension-bootc/blob/c15e40664f11728b8c95eb8213573e0c8af8f8d8/packages/backend/src/constants.ts#L21 exists because we needed a known-stable image builder (didn't want users to get surprised by breaking changes). Discussion about what bib tag tools should use and evolution is tracked here: osbuild/bootc-image-builder#111

[jlebon]

How much extra "integration layer" lives in bootc-image-builder nowadays? I see the partition tables at least are still there.

My 2c on this: I don't think there should be any tight binding to bootc-image-builder. I think the goal should be that you get valid images whether you use b-i-b or Image Builder (that probably translates into "we should make sure all the important stuff lives in osbuild/images instead"). And so b-i-b just devolves to a convenient wrapper around osbuild.

I understand for the short-term though it's useful to be able to iterate alongside b-i-b.

[cgwalters]

I think actually the center of gravity should be the container image, not osbuild/images (and not the hardcoded bits in bootc install either). See containers/bootc#440 which proposes having a generic baseline partitioning setup from the container image, etc.

[cgwalters]

As far as linking to the container versus something else - the other thing about this project is we're emphasizing containers, not RPMs. Sure, we could include a link to an RPM name or something, but if it comes down to it I'd say that the bib container could include links to other alternatives in its metadata. But still though, would anything in reality ever inspect a container image, only to go out and install an RPM from that inspection? Feels...weird. Whereas it will be trivial for things consuming this container image and that are already fetching the bib container to use it, as they're all containers, not RPMs or other things.

[cgwalters]

OK I've rebased 🏄 this one and I think it makes sense to do.