It's my understanding that bootc is not replacing OSTree, it's replacing rpm-ostree with itself and
It's my understanding that bootc is not replacing OSTree, it's replacing rpm-ostree with itself and DNF?
Arpm-ostree has 2 components in it
IThat's my understanding also
Aan image builder and a deployer
RTo begin with, bootc will call rpm-ostree. Then rpm-ostree should be replaced by dnf
Anobody has replaced the image builder yet
NCan't you just use OSTree to build that object and add it to a scratch container?
NJust OSTree, not rpm-ostree.
IOverall, rpm-ostree is used in several important projects and will continue to be maintained for many years to come.
However, for use cases which want a "pure" image based model, using bootc will be more appealing. bootc also does not e.g. drag in dependencies on libdnf and the RPM stack.
bootc also has the benefit of starting as a pure Rust project; and while it doesn't have an IPC mechanism today, the surface of such an API will be significantly smaller.
Further, bootc does aim to include some of the functionality of zincati.
But all this said: It will be supported to use both bootc and rpm-ostree together; they are not exclusive. For example, bootc status at least will still function even if packages are layered.
N@Robert (p5) what was the issue we were having with anaconda? I thought @M2 and I sorted that out a while back.
NIf bootc and rpm-ostree can live in harmony, we should look at adding it back to the images again.
IYes, although rpm-ostree is the only method currently used that I'm aware of
RIt was Bootc Image Builder was too opinionated, and skipped the interactive installer.
Unless I'm thinking of something else
Edit: Oh, I am thinking of something else. Not sure
Unless I'm thinking of something else
Edit: Oh, I am thinking of something else. Not sure
Aostree-rs-ext is responsible for converting an OSTree commit to an OCI image
Aand right now only rpm-ostree extends it, to a non-trivial degree
Ibootc-image-builder appears to be focused on an automated use case, e.g. VMs
Atheres a testing function you can call that makes an OCI image with a single layer
Abut in the code it says that this function should be extended to allow for customization as a TODO
NWe use build-container-installer. Last I remember, that had no issues with creating ISOs that use bootc. Just uses a different command in anaconda. @Skynet would know the more technical details there.
Athis is what my fork of ostree-rs-ext does
RWe've been including bootc in bluefin for quite some time. So maybe that's resolved
SIt works with bootc. I use it with bootc for my custom images
Iostreecontainer is the anaconda command iirc. That's what I'm using in HeliumOS
NWe included bootc just in Bluefin right? Not in our main images because we are waiting on Fedora anyway?
AAlso, certain stuff from the base commit is used as is. This is SELinux and the directory structure with permissions
Aif the base image is too thin, you will get issues with both
RWhat makes a bootc system a bootc system?
I can run bootc status and bootc update. But I can also run rpm-ostree status and rpm-ostree update
Does a bootc system look exactly the same as an rpm-ostree system?
I can run bootc status and bootc update. But I can also run rpm-ostree status and rpm-ostree update
Does a bootc system look exactly the same as an rpm-ostree system?
SBootc works similarly to rpm-ostree for some things, so there's a lot of commands that will work in both. The main thing I've noticed, is that bootc also allows dnf commands during the images build. I'm sure there's other things, but that's the main one I've noticed
Ai think thats due to dnf5 not erroring out
Athey somehow removed the error
ICorrect me if I'm wrong, bootc fetches from an OCI registry, while rpm-ostree interacts with dnf/ostree remotes
Aboth bootc and rpm-ostree use ostree-rs-ext under the hood for OCI right now
Aso they're the same, just a different api
Awhen the podman PR merges this will change
Abut then rpm-ostree will be refactored to use bootc (?)
Aso it will still be the same
RI'm going to try adding dnf5 during the build and seeing what happens when I try and use it
NSo mostly the benefit of bootc is still in the future. We are waiting on podman and zstd chunked.
NAnd also the usage of DNF in container builds.
IEach of my HeliumOS updates are at minimum 2gb
Aalso has some benefits for cloud deployments probably. The bound images are cool
IWith regard to ublue bootc, build-container-installer uses ostreecontainer, so installation iso can be created.
NRight, it just deploys using an OCI dir rather than a URL.
RSorry...
NWow shots fired. He just got in here lol
IWhich tooling creates the current ublue ostree commits?
Kbuildah & rpm-ostree
Kand as long as bootc is in the image
Kand you don't layer anything
Kyou can use bootc on any ublue image today
