It might not be solved yet, I'm now finding that GNOME Software doesn't play nice with read only Fla
It might not be solved yet, I'm now finding that GNOME Software doesn't play nice with read only Flatpak installations 
Nworking on flatpaks themselves make me want to crawl into a hole and cry.
Ndocumentation is...
Nlackluster lol
Iflatpak-builder 
Nbut yeah man, as far as the Alma Linux or CentOS based images, it would just be cool to have that option with all the ublue sauce on them.
NNot exactly sure what @j0rge or anyone else had in mind though.
NWe don't do a ton of marketing around our main images like we used to just because they are really more build infrastructure than anything else.
NAt any rate, really glad to have you here @imbev. Always glad to see more folks in the space doing cool stuff!
IGlad to be here with you and the rest of this community! 
IFortunately the problem is a simple fix: Don't let GNOME Software or Flatpak be aware of the custom Flatpak installation
Bwell main images should be represented as images to base on not images to use anyway
J@imbev welcome!
Jyeah I'd love to have centos as a tag option in the main images. Like we have :latest, :40: 39, it's be nice to do :el10 or whatever so people can just use centos derived images downstream
Jbasically I also want to make a bluefin:lts that's bluefin but on centos.
Jyour stuff looks super cool, I wish more people were making images heh
IThat's certainly possible
IIs ublue infrastructure compatible with bootc yet?
Xublue actually shipped bootc for a moment a while back, but i believe it caused some issue and had to be reverted
Xin my own testing, though, it worked perfectly
ABroke the ISOs
AAnaconda moment
Jyeah we can move to bootc, the biggest issue is waiting for fedora bootc images but looks like the EL folks got those rolling faster than fedora
IThe main obstacle that I see right now is the lack of integration with GNOME Software and the rest of the GUI package managers
Kwe remove rpm-ostree integration from GNOME software today
Knot really an obstacle
Kit slows it down to a crawl and makes it into a terrible experience when it's present
IIn that case, I don't see why it wouldn't work
IThe Fedora images are being produced, however the F40 image is not regularly built IIRC. There are a few projects building personal Fedora bootc images
IIf you take a look at https://github.com/AlmaLinux/bootc-images, it's not too difficult to build a base image
Atheres no such thing as a "bootc" base image yet, if you look under those images you can see theres a little ostree commit in there made by rpm-ostree
Aunless something changed
A
Ibootc uses ostree under the hood
Ayeah
Abut for building images rpm-ostree is still used
IIt's the delivery method that's different
IBy base image, I mean an image that downstream bootc images can
FROM imageyeah but the old ones that we use are bootc images with that definition
NI thought fedora-bootc was building from scratch containers as well? Meaning there is no rpm-ostree step in the process
ICan you send a link to early attempts at ublue bootc?
N@Robert (p5) would for sure have those links.
NHe's also been attending the Fedora bootc initiative meetings more regularly than I have.
NIf you have time on your schedule, it would be cool to get more people going to that!
Acurrently the only projects that can produce base images are rpm-ostree and rechunk
RI don't think we've been doing any ublue-specific investigation for bootc images, but I've got some personal attempts for KDE and GNOME base images here
https://github.com/rsturla/fedora-bootc-base
When I left the repo 3 months ago, they booted into a desktop but had one or two services starting when they shouldn't be.
https://github.com/rsturla/fedora-bootc-base
When I left the repo 3 months ago, they booted into a desktop but had one or two services starting when they shouldn't be.
Athis is what my research lead me to at least
Auntil the podman PR merges for bootc, both bootc and rpm-ostree can only pull images that contain an ostree commit
Aand that commit can only be created by rpm-ostree, if you want it to be chunked
Awell that used to be the case before rechunk at least
IMisclick 
