I see the flatpak thing is being done in a bootc image, but does it inherently rely on bootc though?
I see the flatpak thing is being done in a bootc image, but does it inherently rely on bootc though?
II'm actually the dev of that project
Iflatpak-readonlyroot reads toml config to configure a custom Flatpak installation, it's not specific to bootc. The name reflects the intended use case rather than technical limitations
IWhat do you have in mind?
NVery nice! Do you know if the flatpaks that get installed resolve all the dependencies during installation?
IThanks 
Yes, all dependencies are resolved
Yes, all dependencies are resolvedIThe main downside of this approach is the increased filesize. e.g. platform dependencies are not shared between the flatpak-readonlyroot installation and the typical flatpak installations
Noh, so they only update on image build?
Ncould be nice for some stuff I suppose.
IYes, the flatpaks are completely managed by the mechanism that delivers /usr instead of flatpak's package management
NI could seeing this being useful specifically for like the gnome apps and such.
Nstuff you typically wouldn't want a user to uninstall.
IExactly, I'm currently using it to deliver bootc-gtk
Ndefinitely gonna load your project up in a VM. Very interested to see what bootc-gtk looks like.
Nand other things you are doing.
IThanks
Noh you have it on the site lol
IIt's recently AlmaLinux-based instead of CentOS Stream
Noh nice! Yeah, I was thinking about playing around with the Alma Linux bootc images.
IThey're just like the CentOS Stream images, but minor-version stable
Nfor sure!
NLooks like you use Lorax to build your ISOs?
Noh I see, yours is a netinstall as well.
INo, actually. The isos are upstream AlmaLinux boot isos, with some configuration swapped out
NOH ok, so you're just editing the ISO and using a kickstart.
Nthis would make it a netinstaller here.
INSo one challenge you might find is that with a netinstall if your image gets any bigger, you will have install failures from users.
Nwe ran into that problem and ended up moving to: https://github.com/JasonN3/build-container-installer/
GitHub
Creates an ISO for installing a container image as an OS - JasonN3/build-container-installer
Nmakes your ISO quite a bit bigger, but it is fully offline.
Nyou can also declare your flatpaks as part of install.
Nrather than bundling them into the image itself.
IThat's very powerful
NIt's really helped us a TON.
NI really would love the netinstall option to have retries, but good luck with getting the Anaconda team to implement any features right now.
Nthey are BURIED.
IMy main concern with that approach is that the infrastructure will expand beyond mkksiso and podman, but I'm reaching the limits of that as is
NI love what you are doing here though, very cool stuff with bundling flatpaks as part of the image.
NI don't believe anyone had solved that problem (up to this point) yet that I was aware of.
Nyeah, I totally get that.
IIt 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!
