Band it woild be hard to achieve currently at least with seperate partition
DuFixit yourself
J
Jcolin sent me this
Jif someone has time to go dig in and see what you can find that'd be awesome, context:
JBTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base
- it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native". It's just a rough draft so far, I haven't tried using it "in anger" like to build a desktop with or anything, but I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.
Dhttps://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base#adding-arbitrary-content-making-arbitrary-changes
this is interesting, so DNF is being used instead of rpm-ostree?
this is interesting, so DNF is being used instead of rpm-ostree?
RDNF being used in the "builder" container, which is regular Fedora
This is then packaged as an OCI archive somehow and copied to the scratch image
This is then packaged as an OCI archive somehow and copied to the scratch image
Bi can look into this but yea as far as i know he want to achieve the end in which you deploy oci image without any ostree bits at all
Bwhat im sitll waiting for is bootupd to be able to do any distro
Bi really want to be able to make some other distros not just fedora
EThe build rationale is really comprehensive: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/README-build-rationale.md?ref_type=heads
FResetting gsetting is also useful & something I do in my image
Blooking at the containerfile its quite genious and works based on fedora:40 image not some special rpm-ostree image
ELooking at the build scripts and it's brilliant
EThis reminds me of how we handle 
-base(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
silverbluekinoiteit 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: @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