Which tooling creates the current ublue ostree commits?
Which 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
IWhat I mean to ask is how are ublue images currently built? I see https://github.com/castrojo/ublue, but that appears to be no longer used?
RIf you use bootc on an existing ublue image, is it any different to an image where you started with bootc from the beginning?
KGitHub
OCI base images of Fedora with batteries included. Contribute to ublue-os/main development by creating an account on GitHub.
IHow does rpm-ostree handle /etc?
Ait doesnt
Aostree does
Awith a 3way merge before rebooting to the new deployment
Anew files and changed files remain
Ain the new image, and replace the new image's /etc
IThat behavior is shared by bootc
Kbecause bootc uses ostree
Abootc is a thin layer over ostree so yes
Kit's all ostree
NAll roads lead back to OSTree lol. I wish rpm-ostree was named something different. I got confused by that for the longest time.
Athe fedora bootc repo is kinda cursed imo
Athe way they build the base image is very complicated
ILooking at https://github.com/ublue-os/main/blob/main/Containerfile, the install scripts will need to be replaced by bootc configuration such as https://gitlab.com/fedora/bootc/base-images/-/blob/main/tier-0/kernel.yaml for the base images, and regular dnf commands for downstream images
A
Iinclude this.yaml, include that.yaml 
Ayoure not meant to use as an end user
Abecause everyone here was like no
Ai aint using that
Almao
Ai had suggested it
Ireally? I expect that'll make migration easier
AColin found his niche, people like containers, so everything is a container now
Aand the treefile stuff went out the window
RTimothee currently maintains that rpm-ostree compose stuff, and will eventually move over to the bootc base images when things like local layering is sorted
So the raw compose files will hopefully always be abstracted away from us
So the raw compose files will hopefully always be abstracted away from us
IDoes that handle all of ublue configuration? Or is that only for base images?
RThis is just the base images. So basic hardware enablement and unopinionated changes.
More opinionated images (Bluefin/Bazzite) use the images built in ublue-os/main as base images in their containerfiles
More opinionated images (Bluefin/Bazzite) use the images built in ublue-os/main as base images in their containerfiles
IOk. Is there anything preventing usage of dnf within the downstream Containerfiles?
Ayeah, an error condition
Abut other than that theoretically nothing
IA migration to bootc would make that possible instead of using
rpm-ostree installAsomething in fedora-bootc enables it
Awhich is not done if the image comes from the other repos
Aif you do that dnf will work in your image
Abootc is broadly a rebrand of the portfolio,
rpm-ostree install is a reimplementation of dnf install when running in a containerAthe problem with building base images using OCI is preserving permissions
Auntil ubuntu 24, containers used to crap on permissions so the image would not work afterwards
Abut now that is much less of a problem if you use a recent podman
Fdnf5 appears to work in a Containerfile, but can't guarantee if there are some micro-issues with it, like with missing SeLinux labels, permissions & suchAevery selinux label you add in a container is thrown away
Awhen it is deployed
Apermissions-wise, recent podmans are good but there are quirks there
