Add `bootc build commit`

[cgwalters]

This should take over the role of ostree container commit, however following up on ostreedev/ostree-rs-ext#569 we can change our thoughts on /var.

[vrothberg]

Can you sketch out where bootc build commit would be called? Dockerfile/Buildah?

[cgwalters]

Yes as part of a RUN invocation

[jmarrero]

@cgwalters any reason for this not to be a pass-thru to ostree-ext for now?

[cgwalters]

One reason is we kind of just did a pivot around our handling of /var since ostreedev/ostree-rs-ext#569 - and while this needs more testing and validation - we may want to degrade the /var bits to a warning for example.

A tricky thing about making it a literal re-exec style passthrough is right now ostree container is shipped by rpm-ostree, and ultimately we want to support bootc-only images, so we probably want to expose the container commit processing as a Rust API. Or possibly we split it out into a separate component/package.

[cgwalters]

This issue also relates to #215 in that ultimately what we'd do here wouldn't involve ostree per se. But we'd need to then figure out something around the thorny issue of how we represent these xattrs (xref discussion in containers/storage#1608 )

[jmarrero]

Just a heads up that we are working this issue on our mobbing sessions. Specially based on this comment:
#217 (comment)

I am not sure if this is intended to intersect with: #365

[cgwalters]

I am not sure if this is intended to intersect with: #365

They're very different things, which argues for using different verbs.

[cgwalters]

I'm a bit uncertain about doing this versus offering a container image that can work as part of a multi-stage build and do this stuff. That's inherently maximally flexible and avoids shipping potentially all sorts of tools in smaller images.

i.e. we'd document:

FROM quay.io/someuser/useros:latest as rootfs
FROM quay.io/exampleos/bootc-image-tool
RUN --mount=type=bind,from=rootfs,target=/sysroot bootc-image-scan /sysroot

Now don't get me wrong, it does seem quite convenient to ship basic scanning stuff as part of the image itself so you can just stick a RUN bootc build-scan or whatever as part of your single image flow...but on the flip side, this isn't something that exists in the podman/docker ecosystem by default.

If we take the "bootc does one thing and does it well" philosophy then this may end up being outside it, right?

I could go either way...

BTW one thing that we should have a basic lint checker for is having a single kernel (like rpm-ostree does).

[jmarrero]

If we take the "bootc does one thing and does it well" philosophy then this may end up being outside it, right?

I can always be persuaded by the original Unix philosophy. I say we close this then.

[cgwalters]

I keep going back and forth honestly 😄

One thing here is that while we have a stance that bootc is not a build system (you can use any container build system) there are in reality some rules it enforces specifically (such as the "one kernel" rule).

Even if we had an external tool, it could call out to bootc build-lint or whatever we call it for that set of rules.

But we should probably think about what other things we need to lint for. There are potentially a lot...but I don't know how much is bootc specific in the end, versus "generic Linux" stuff.