Some questions after messing around with the Cinnamon image

[mister-drgn]

So first of all, as of last night the Cinnamon image is working (I haven't tried the nvidia version), and I'd welcome people to try it out. That said, I have a few thoughts and questions based on what I'm seeing right now.

1. If you start out with Silverblue and then rebase off the cinnamon image (or the other ublue images), you end up with a set of gnome-specific flatpaks from Silverblue. These are pretty annoying to have around, as they show up in the menu with the same name as cinnamon apps (e.g., "Extensions" and "Text Editor"). I'd like to add a script that can be used to delete them. Of course this script shouldn't run by default because people might want to go back to silverblue after experimenting with cinnamon.

2. On the other hand, there are some flatpaks I'd like to add after a user rebases off the cinnamon image. In particular, I'd like to add the flatpak add-ons for various Cinnamon themes (these all have names like "Mint-Y-Dark-Blue"). These seem to allow some flatpak apps to be responsive to the theme that gets set in cinnamon, although other flatpak apps ignore the theme. Unlike 1) above, I wouldn't mind if these were installed by default (recognizing that this requires running a script on initial startup, since the image can't touch the /var directory).

3. I have some ideas about how to address items 1 and 2, but perhaps the "standard" ublue way would be through the ublue-os/config package? Could anyone offer suggestions here?

4. I want to offer a GUI option for installing flatpaks in Cinnamon. From what I can see, the best option is gnome-software. I don't love the gnome-software app because it appears to ignore all theming--I can't even find a way to set it to non-light manually. But I don't know of a better option. I considered that people could download from flathub directly, since they just redesigned the website and it looks pretty nice, but downloaded files aren't automatically loaded. So it looks like I'm stuck with gnome-software, unless anyone knows of another option.

5. I'm interested in forking off ublue-os/cinnamon to make my own custom image, which will include things like touchegg (unless it makes sense to include touchegg in ublue-os/cinnamon...more touchpad gestures is nice). I'm not sure of the best way to handle the fork, however. Right now, the cinnamon image is built off of ublue-os/base-main, which is built off of quay.io/fedora-ostree-desktops/base. So I could A) build my custom image on top of the ublue-os/cinnamon image, or B) fork the cinnamon image code and build on top of the ublue-os/base-main image, or C) fork both the cinnamon image and main image code and build my own pair of custom images on top of quay.io/fedora-ostree-desktops/base. I suspect that B) is the most reasonable approach.

Thanks.

[castrojo]

Check out: https://github.com/ublue-os/yafti/

That's what I use to run pre commands to swap out flatpaks and stuff as well as a nice gui on first run that the user can use to install what they want. You're probably stuck with gnome-software as your day to day store though.

As to how to fork it, right now you're the only one having an opinion on the image so if you want to add things like the gestures then I say go for it!

I would recommend method A), which is what I do for bluefin. I would just FROM ublue-os/cinnamon in your own custom image. When there's something that you feel is useful for all Cinnamon users, put it in this image so that it becomes better over time, and then for things that are just opinion (app choice usually) then put that in your custom image.

I think we want to encourage people to split it this way for two reasons. First it forces you to think of logically splitting what should be in a common image, and what's your personal preference. By doing it this way people would be encouraged to help maintain the base image by sharing the work, and then have exactly what they want in their custom image.

[mister-drgn]

Thanks, yafti looks great. I'm trying it out today. A couple more things:

1. How exactly does "run-on-change" work with yafti? If I rebase to bluefin, then rebase to something else, then rebase back to bluefin, I'm guessing the flatpak installer won't run again? There must be somewhere in your home directory where yafti records that you already went through that process, unless it updates every time you rebase.

I expect rebasing to multiple images that use yafti could get messy, but rebasing to multiple images is going to get your home directory messy anyway.

2. I guess my concern about chaining images (e.g., basing a custom image off the ublue cinnamon image, which is based off the ublue base image, with is based off the quay.io base image) is that you have multiple points of failure. And because, as you mentioned, you only get new images when everything builds correctly, these are silent failures. Suppose, for example, that the images on quay.io stops updating for some reason (are those official images distributed by fedora?). The ublue images will go right on building, only with stale packages from the last-built quay.io images. That would continue until those stale packages become incompatible with the ones ublue is adding, or maybe the ones I'm adding later in my custom image, at which point one of those images will also stop updating. Meanwhile, all the end user sees is regular updates until the final image in the chain stops building, and then no updates.

Am I understanding that correctly? So then it seems important that someone maintaining any image along the chain keep an eye on the health of all the images earlier in the chain.

Also, it's probably a good idea to keep an eye on when earlier images in the chain are being built, since ideally you want to build your image right after the image that serves as its base is built, to maximize the chances that the base image and the packages you are adding are in sync--it looked like someone made some recent changes to ublue to do this.

All of which is to say, maybe there are advantages to keeping your chain shorter.

[castrojo]

I'll let marco answer the first one since I'm not familiar with how that works.

And because, as you mentioned, you only get new images when everything builds correctly, these are silent failures

They're not silent they show up as red on github and people notice almost right away. 😄 I don't think we've had a time where we've had an image broken for over a day without anyone noticing (other than the first time, heh) and https://quay.io/organization/fedora-ostree-desktops tells us when the last Fedora ones were published (and it's in the metadata so we can check there too)

[castrojo]

Looks like it's running pretty smoothly now. 😄

[mister-drgn]

Thanks, I think the base image is in a largely finished state. I don't see much more to do.