use official upstream Atomic Desktop images (once they support bootc) insted of current unofficial

[bsherman]

We want to migrate to official upstream Fedora bootc images as the foundation for Universal Blue images.

Upstream builds:

• fedora-bootc
• fedora-kinoite
• fedora-sericea
• fedora-silverblue

These all map well to the following existing images:

• base
• kinoite
• sericea
• silverblue

So the transition would be change the "FROM" on these images from quay.io/fedora-ostree-desktops/silverblue to quay.io/fedora/fedora-silverblue etc. base would be FROM bootc.

This change is blocked until Fedora F41 enables bootupd for BIOS systems:

• https://tim.siosm.fr/blog/2024/10/30/fedora-atomic-desktops-41/#bootupd-enabled-by-default-for-uefi-systems-bios-coming-soon
• https://gitlab.com/fedora/ostree/sig/-/issues/1

The primary change to the project, other than being built from official upstream images, is we will not have official upstreams for lazurite (LXQT), onyx (Budgie), and vauxite (XFCE). So those desktops will be removed.

We should probably mark them as "deprecated" ASAP.

Notes from team discussion: Also these changes may be related:
https://pagure.io/fedora-infra/ansible/pull-request/2337
https://pagure.io/releng/issue/12142

[castrojo]

The latest lazurite-main has 21 pulls: https://github.com/ublue-os/main/pkgs/container/lazurite-main/versions

The latest vauxite-main has 92 pulls: https://github.com/ublue-os/main/pkgs/container/vauxite-main

lazurite is probably scanner noise, let's nuke it, but there's probably a handful of xfce folks on those images. Timothee says this on an official xfce image, so we can probably point to people there if they want to continue getting support.

[alexsch01]

Curious, I thought the bootc images don't allow layering, is that still true?

[bsherman]

bootc is the future of Fedora Atomic Desktops and CoreOS, so it's our future.

Local layering has never been a goal of Universal Blue as I've understood it. The vision has always been a future where that's not required. Local layering has been a painful occasional workaround.

All said, I should answer your question 😃

No bootc does not support local layering, but we will still have a container native rpm-ostree backend, so users wanting to local layer can still use rpm-ostree for that purpose.

Switching our source images is an important step but will not automatically change everything to upgrade via bootc, which is where local layers would be dropped.

[castrojo]

bootc tells the user what to do:

# bootc update
ERROR Upgrading: Deployment contains local rpm-ostree modifications; cannot upgrade via bootc. You can run `rpm-ostree reset` to undo the modifications.

[gerblesh]

As per issue: https://gitlab.com/fedora/ostree/sig/-/issues/48 and https://pagure.io/releng/issue/12142
bootc, bootupd, and dnf5 should now all be working on the official images. I'm not sure if we want to move right away, if we were to switch, we would likely have to only move images that are F41+

[castrojo]

Not sure if this should be a separate issue, but I think we can drastically cut down on the amount of images we generate by taking advantage of the bootc/dnf work more directly.

Here are all the groups in there so far: https://gist.github.com/castrojo/6dc7ca127b1976052dfb03d8376fe7d7

I was able to add COSMIC and it's apps to my custom image with one line, check it out: https://github.com/castrojo/achillobator/blob/main/build.sh

I could do the same with budgie if I wanted. In the past due to rpm-ostree's limitations we ended up trying to make finished desktops by doing the individual packages and then adding in all the QoL. Now with dnf we can just use the existing Fedora groups, which means a custom image can look like:

FROM ghcr.io/ublue-os/base-main        
RUN dnf5 install $desktop-group apps-I-want

and you're done. Then instead of trying to make an nvidia variant for each desktop people ask for they'd derive from base-nvidia instead. There'd be no need to explode the matrix for every time someone wants a new window manager, they can just use the existing dnf groups, which are the exact same ones workstation uses.

Then bluebuild can do a desktop: budgie module or whatever.

It also means that when we deprecate an image, say XFCE, the people who want it have a path forward. They go from:

FROM ghcr.io/ublue-os/vauxite-main
RUN $all_my_stuff

to

FROM ghcr.io/ublue-os/base-main
RUN dnf5 install xfce-group-thing
RUN $all_my_stuff

Also, if Bazzite wants to do Budgie and COSMIC desktops they can just install those groups right in their repo and build it there instead of us having to amplify the matrix for every desktop.

[tulilirockz]

That will require a tiny bit of curating since dnf5 does not install a ton of dependencies that rpm-ostree installs automatically, like, gnome-bluetooth, gnome-remote-desktop, and others for some reason! - But this seems like the best way going forward for SURE, it will let people more easily customize their own images, itll make it so they can have super stripped down things, will make the maintenance burden a lot lower on the main image, AND it also will make it a ton easier to change bases if someone wants to

[tulilirockz]

and it also deincentivizes main image usage by literally not having them!!! GREAT idea to be completely honest

[KyleGospo]

Not sure if this should be a separate issue, but I think we can drastically cut down on the amount of images we generate by taking advantage of the bootc/dnf work more directly.

Here are all the groups in there so far: https://gist.github.com/castrojo/6dc7ca127b1976052dfb03d8376fe7d7

I was able to add COSMIC and it's apps to my custom image with one line, check it out: https://github.com/castrojo/achillobator/blob/main/build.sh

I could do the same with budgie if I wanted. In the past due to rpm-ostree's limitations we ended up trying to make finished desktops by doing the individual packages and then adding in all the QoL. Now with dnf we can just use the existing Fedora groups, which means a custom image can look like:

FROM ghcr.io/ublue-os/base-main        
RUN dnf5 install $desktop-group apps-I-want

This is a -1 from me, group install is cool but Spins do a lot more than a single group install command can get you, and we'd lose out on all of that work.

[noelmiller]

Not sure if this should be a separate issue, but I think we can drastically cut down on the amount of images we generate by taking advantage of the bootc/dnf work more directly.

Here are all the groups in there so far: https://gist.github.com/castrojo/6dc7ca127b1976052dfb03d8376fe7d7

I was able to add COSMIC and it's apps to my custom image with one line, check it out: https://github.com/castrojo/achillobator/blob/main/build.sh

I could do the same with budgie if I wanted. In the past due to rpm-ostree's limitations we ended up trying to make finished desktops by doing the individual packages and then adding in all the QoL. Now with dnf we can just use the existing Fedora groups, which means a custom image can look like:

FROM ghcr.io/ublue-os/base-main        
RUN dnf5 install $desktop-group apps-I-want

and you're done. Then instead of trying to make an nvidia variant for each desktop people ask for they'd derive from base-nvidia instead. There'd be no need to explode the matrix for every time someone wants a new window manager, they can just use the existing dnf groups, which are the exact same ones workstation uses.

Then bluebuild can do a desktop: budgie module or whatever.

It also means that when we deprecate an image, say XFCE, the people who want it have a path forward. They go from:

FROM ghcr.io/ublue-os/vauxite-main
RUN $all_my_stuff

to

FROM ghcr.io/ublue-os/base-main
RUN dnf5 install xfce-group-thing
RUN $all_my_stuff

Also, if Bazzite wants to do Budgie and COSMIC desktops they can just install those groups right in their repo and build it there instead of us having to amplify the matrix for every desktop.

Yeah, I agree with Kyle here. If we wanted to get rid of less used ones like vauxite and others, I would be in favor of that first before redoing all the work that Timothee and the spins are doing for us.

[noelmiller]

Also, probably separate issue, but we could look at starting to migrate to using DNF5 rather than using rpm-ostree.

[tulilirockz]

Not sure if this should be a separate issue, but I think we can drastically cut down on the amount of images we generate by taking advantage of the bootc/dnf work more directly.
Here are all the groups in there so far: https://gist.github.com/castrojo/6dc7ca127b1976052dfb03d8376fe7d7
I was able to add COSMIC and it's apps to my custom image with one line, check it out: https://github.com/castrojo/achillobator/blob/main/build.sh
I could do the same with budgie if I wanted. In the past due to rpm-ostree's limitations we ended up trying to make finished desktops by doing the individual packages and then adding in all the QoL. Now with dnf we can just use the existing Fedora groups, which means a custom image can look like:

FROM ghcr.io/ublue-os/base-main        
RUN dnf5 install $desktop-group apps-I-want

This is a -1 from me, group install is cool but Spins do a lot more than a single group install command can get you, and we'd lose out on all of that work.

I just checked out the official fedora silverblue yaml files they use to build and we would literally just be losing out on this:
https://pagure.io/workstation-ostree-config/blob/main/f/silverblue-common.yaml

They literally just use the DNF groups for the official images anyway
https://pagure.io/workstation-ostree-config/blob/main/f/comps-sync.py

[castrojo]

We can probably keep silverblue and kinoite and yeet the rest since those are the ones we're using for the downstreams anyway.