This reminds me of how we handle `-base` packages in Wolfi 🙂 - https://gitlab.com/bootc-org/fedora-
This reminds me of how we handle 
-base packages in Wolfi 
E(but obviously not as clean, but it can't be given they have to work with specs)
EThey also have inconsistent pulls from Quay 
Bforget "significantly reduces" this nearly completely removes rpm-ostree from our consciousnesses regarding image builds!
pretty impressive!
and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm
pretty impressive!
and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm
Jyeah
Fhow would the local user uninstall the "dnf" package from this experimental image?
Jugh git submodules, don't like that
Bthe local user would not.
the entire design is to build images ... you want to customize? you build a new image with the changes
the entire design is to build images ... you want to customize? you build a new image with the changes
Jyeah this is the full move to The Final Shape, you're not bringing all that stuff forward, pure cloud native.
Bi actually think the reuse of spec here is pretty nice... it's well definied... rhel/fedora are very much RPM-centric, so resuing that to compose the whole OS image is cool
ENo problems there at all!
EI think it's great
Jyeah it lets you skip a step
Jlike imagine if we're just putting the specs in here
Bi don't read that as "git submodules are required" for custom images... just a possible way if you want to rebuild the world
Jfile issues and leave feedback, the more we give feedback the less work for us in the future.
Jyeah I know I was just in the mood to maybe try it now I'm like, ugh every time I run into those things it ruins an afternoon for me
Jthen I realized ya'll will do a better job playing with it than me
RPretty sure this pattern isn't meant for us. This is how Fedora is hoping to build their
silverblue, kinoite etc images which we then consume in the same way we are nowit significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native".
...
I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.
Bbiggest concern i see, this will be a major paradigm shift for existing Fedora Silverblue users... mostly due to the lack of local layering...
so, politically in Fedora, maybe that's a problem..
but for us, it would be awesome...
I'd love to take a bootc Fedora Silverblue/Kinoite as our foundation for our images... MUCH cleaner
so, politically in Fedora, maybe that's a problem..
but for us, it would be awesome...
I'd love to take a bootc Fedora Silverblue/Kinoite as our foundation for our images... MUCH cleaner
Jyeah but also that work is taking forever and basically stalled, I wonder if we can combine this with other work
Jfedora will keep the rpm-ostree stuff in a while, I wouldn't worry about that, they're thinking what they have for 2028
Jbut maybe we can get efficiency wins with fedora-ostree-desktops + main / hwe as "ublue 2.0" or something.
EI've tried to word this as best I can but I'm struggling so I'll keep it short... What if we just built the base images ourselves in this instance? We can help improve this as a base and utilize it as a submodule when we go to build our main images. Completely untether ourselves from ostree-desktops/the official images
JYeah, I can see use cases for that.
JLike what if main/hwe were just all composed in one step and the bazzifinrora was the first FROM
EI certainly can, especially if aarch64 images are indefinitely on the back burner
EThat would be amazing
Ja person at github who can help us with arm builders just put bluefin on her laptop. 
Jit's only a matter of time, we'll get our builders, but it would be nice to ensure we got what we need ahead of time so when we do get them we're not stuck
RI'm sure I've asked before, but cannot remember the answer.
We can build ARM docker images already using the
We can build ARM docker images already using the
arch: parameter in the build workflows. Is this not suitable for us?J@bsherman colin seemed to resonate with the coreOS kernel idea and a weekly cadence. But when I mentioned recomposing silverblue from the bottom up he was pretty much "yeah that's a lot of work"
EThat would be amazing. Definitely want to make sure we're good to go but unfortunately, it sounds like upstream is in limbo with getting ARM images out the door right now (they have everything set up for it but just aren't building them)
EYeah, I have a PR for this
RBy "yeah" do you mean it doesn't work? Or we're trying to get it merged?
EIt doesn't work because aarch64 images aren't being built upstream
G
Nwhoah, i feel pressured to do it with that headline
Nlmao
Ni love markdown formatting
GYeah...
EGoing to mess with this idea a bit this weekend. After I get Wolfi images in a good state
Byeah, that's what I would expect.
Jdid something break with the wolfi boxes?
ENo, I just really want to roll out apko based images. Apologies for the confusing wording
Jthis sbom stuff would be great to highlight in our talk too, great infra feature!
EFor sure!
JI met Ariadne and the entire crew at OSS Summit.
GThis could get rid of the bind mounting workaround for stuff like swtpm and waydroid
EThat's awesome! I had thought about going for a while
Bi think it could be a solution for the new problems with F40 builds
