the way they build the base image is very complicated
the 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
Jcan someone paste in the architecture diagram for imbev? sorry in a call
J@Kyle Gospo jeefy at work is like "aww ublue, how cute."
J^^^ CNCF's runners firing on all cylinders today
IWhat I'm seeing as a difference is that ublue is using
ostree container commit for each layer of the image, while bootc-derived images are able to use the Container's own layers without that step.
Knot required, that was a recent change
Kthat just does some cleanup prior to layer generation, such as wiping out temporary files
Aostree container commit cleaned var essentially
A
Universal Blue
Hadn’t heard of that specifically, but had herd of similar projects. Didn’t use one, because I didn’t have time to learn one, and I think the results would be less aesthetically pleasing.
Aif you use rechunk it will also clean var so you dont need it
Ai should try to build kinoite using "from fedora"
Athat would be a flex
Afuture plans
II'm thinking of the following:
- Refactor ublue-os/main to
FROM quay.io/fedora/fedora-bootc:VER, replace rpm-ostree calls with standard dnf calls. There're a few hacks that need to be done with bootc, but it can otherwise be treated like mutable fedora most of the time within the Containerfile - Refactor downstream images in the same way
- The rest might be able to be reused as is
IWould a branch or strangler strategy be preferred?
RWe could, but then we have the added burden of managing package lists for Gnome, KDE etc, which we don't currently do
Right now, we just
Right now, we just
FROM quay.io/fedora-ostree-desktops/{silverblue|kinoite|something}:VER and it's all managed by othersIIs there a significant difference between the atomic desktops and the mutable variants using the corresponding package group other than the immutability?
NTimothee would be a good one to ask on that. He is in Matrix in the Atomic desktops channel.
NI don't see him too often in here.
Jhah yeah this is what we're supposed to be doing, we got some repos we cloned as main-bootc, hwe-bootc, etc but I don't think we're using them
JI'm not sure if we need to have a ton of new repos, we could just opportunanistically snag swap the common ones like gnome/kde, as those come online.
IIt'd be simple to switch the base image and remove a
dnf groupinstall once upstream Fedora produces them