+1

+1

I don't really have an informed opinion on this, because I know nothing very little about the ostree build process. Containerfiles are a design mistake, but I trust that the people working on this know what they are doing.

+0

Yeah, same as ↑ (note that @zbyszek started his comment with a0. vote that got parsed as an enumeration that starts with 1., so it looks strangely formatted in markdown but is clear in plaintext).

I think Dockerfiles (let's not lie to ourselves about "Containerfiles") are hugely flawed and a core design mistake, but I'm fine with letting the FCOS people go down this path if they want to.

+0 (with a leaning to -1 should it come to it).

(I fixed the formatting of @zbyszek's comment so his vote shows up properly.)

Personally I do not like how Containerfile work, but it seems to me that they became the de facto standard to create containers, so it does make sense to use them, also considering the advantages that using a standard approach would bring.

+1

I am not a fan of containerfile either, but since bootc already uses it... unless Neal files a change proposal to use Kiwi to generate all containers then this is at least more standard

+1

I am not a fan of containerfile either, but since bootc already uses it... unless Neal files a change proposal to use Kiwi to generate all containers then this is at least more standard

I don't know enough of how a bootc formatted container must look to be able to implement this in kiwi, otherwise it would be done already.

Personally I do not like how Containerfile work, but it seems to me that they became the de facto standard to create containers, so it does make sense to use them, also considering the advantages that using a standard approach would bring.

FWIW as the Change Owner this sums it up for me as well. Even with all its flaws, a lot of the container building ecosystem is built around it and it'd be working against the grain to try to do something different.

I also think there are ways to counteract some of those flaws. Specifically in this case, for FCOS we're using the FROM scratch flow which really still boils down to doing an rpm-ostree compose as part of the build, and getting a sensibly chunked layered final image. And e.g. rpm-ostree treefiles are still used as a declarative front-end for package lists, and lockfiles still give you good change detection, etc.

But shaping that as a container build means it's pluggable in lots of build services, like Konflux. And contributors can now build FCOS themselves much more easily without having to know about coreos-assembler.

Approved (+4,3,0)

Announced.