Ability to control the set of "batteries"?

[calebcartwright]

Hi there 👋

I'll preface first by saying that uBlue seems like an absolutely fascinating project that's already achieved some impressive results, and secondly issue a preemptive apology if I'm asking in the wrong place (and/or if this has already been asked and answered, my GitHub search skills didn't turn anything up).

In short, I'm trying to understand if making a custom DIY image will result in inheriting the packages added as part of the main image, the so-called 🔋 😄, and if so:

*whether that's something that can be readily controlled by the custom image producer (i.e. assume I wanted to skip/remove one of the batteries added to main, is that possible, and if so, how deterministic/maintainable is that? could I define my own include/allow list of such battery packages, or if/when new packages are added to main would they automatically flow into my custom image unless/until I took some specific action to exclude them?

• if not, or if it's difficult/cumbersome/manual/etc. to exclude new packages from popping up in custom images by default, would you consider some form of a "stock" silverblue (a "from scratch" type variant) that has none of the 🔋 packages added as part of main?

[castrojo]

It's hard to answer this without specifics, what are you trying to build?

[EyeCantCU]

It's definitely possible to remove packages from the base you're building from. See the recipe in startingpoint as an example

You could alternatively (if you're not using startingpoint) throw something like this in your containerfile

RUN rpm-ostree override remove PACKAGE

Building from main, you'll inherit all the packages in main, or from any base you may choose to use

[calebcartwright]

@EyeCantCU

Building from main, you'll inherit all the packages in main, or from any base you may choose to use

Thanks for confirming, that was my understanding

It's hard to answer this without specifics, what are you trying to build?

@castrojo

Let me know if I've misunderstood or am missing some context, but I feel like my question is more general to the process/capabilities and independent of specifics.

Essentially, I like the Universal Blue model. There are a handful of packages I'd want in my Silverblue environment that aren't readily available/viable as Flatpaks, but I'd like to avoid having to deal all the ostree layering activities myself; hence my interest is quite piqued by uBlue.

I understand the reasoning behind the most foundational uBlue image (which I understand to be main) having some quality of life improvement packages added, however, the list of packages in main includes several things I wouldn't personally want (that's not intended to be a knock against any of those packages, there's just things in that list I'd never use and as such wouldn't want to have installed in my env). Additionally, there's a couple packages not in the main list which I would want.)

Given that, I don't think there's any existing images I could just use out of the box, so I've been contemplating using your tooling to create my own. However, even if I go that way, I feel like I'd be looking at some manual overhead to maintain my desired list of packages.

For example, if I were to use some of the existing techniques that @EyeCantCU noted above, I fear I'd be perpetually having to manually adjust things to skip "upstream" package changes coming from main. E.g., for the sake of simplicity let's assume the only package from the default set in main I want to exclude is just: I could certainly structure my image to remove that. However, if in a day, week, month, etc. some new package foo is added to main that I also do not want, I'd have to (a) know that foo had been added to main and then update my custom image again to explicitly remove foo (the same concept more or less applies if packages are ever removed from main).

Ultimately, I'd like to be able to more easily control the set of packages in a custom image, and be able to do so without having to constantly keep tabs on and react to package changes in the base image

Does that help clarify my question/use case?

[calebcartwright]

When it comes to what you're saying here, I feel like there's some give and take. No matter what image you use as a base, whether it be ours or the ones provided directly by Fedora,

Sure, but I'd note that (a) the value prop of uBlue extends significantly beyond the singular set of opinionated quality-of-life packages selected by the maintainers/community for main and (b) one of the benefits of the reprovisionable/anti-hysteresis/immutable/image-based OS is the ability to have greater (and more reproducible) control atop the same base as the upstream devs.

I don't know how core you all consider the set of quality of life packages to be to Universal Blue, but fwiw my $0.02 as an interested outsider is the biggest value value prop is the overall image based paradigm. I recognize there's a shift in that main is the base, the upstream devs are the uBlue team, and that main is significantly less opinionated than e.g. bazzite. However, I'd argue main is still opinionated itself given the list of packages, and I'd like to be able to use the uBlue paradigm with the Silverblue base set of packages (perhaps this is wanting to both have and eat my 🍰 though)

That's why I was curious whether you might ever consider something like

scratch (or a better name, no packages/opinions added)
main (functionally the same as today, based on scratch but adds those QoL packages)
... everything else continues to be based on main

Perhaps I've a more esoteric perspective on this, and the overwhelming majority of current and future users will want/accept the entire set of packages main provides. However, I personally suspect that won't be the case as the user base grows (we Linux folks are a rather opinionated bunch 😅), and that'd be beneficial to make the uBlue paradigm more easily consumable for such users that have different opinions about the packages.

Anyway, just my opinion. I'll spend some time looking at the pull app at some point in the future and see if I can make that work for my needs, thanks for taking the time to help with my questions!

[castrojo]

I think the scratch use case is covered by the stock fedora images already? They only have a few but they'll eventually have everything in quay.io/fedora. It's what we will eventually base our images on. Or you can also skip us entirely and do it from these images: https://gitlab.com/fedora/ostree/ci-test/ -- which are unofficial but more stock than ours.

[castrojo]

Those images end up here btw: https://quay.io/fedora-ostree-desktops/

[calebcartwright]

Those images end up here btw: https://quay.io/fedora-ostree-desktops/

Interesting, thanks for sharing! I haven't been following the upstream news super closely, but was under the impression those likely wouldn't be viable until Fedora 40 or beyond (based on things like https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable)

[castrojo]

It's what we've been using for the past year or so already, we were hoping to switch to official images but now we get an extra 6 months to test, hah. They were on track for F39 but got punted to F40.

[castrojo]

I'd like to be able to use the uBlue paradigm with the Silverblue base set of packages (perhaps this is wanting to both have and eat my 🍰 though)

Yeah I think it's totally feasible, this is the pattern Fedora is already heading in so we're more here to see how well it works. Most of the stuff here will become redundant when Fedora eventually gets there, it'll (hopefully) just be part of the distro tooling upstream.

We purposely don't call it the "uBlue paradigm" since it's not new. It's a cloud-native pattern, we talk about it a bit on the website: https://universal-blue.org/ under "Why would I use these". We're just reusing a common pattern from application developers but the container happens to have the rest of the OS in there (with the kernel) already. Which is way cool!

[calebcartwright]

Most of the stuff here will become redundant when Fedora eventually gets there, it'll (hopefully) just be part of the distro tooling upstream.

Unrelated to my original question but this was one I was wondering about as well; my understanding from some cursory reading of various material within Fedora and OSTree was that they seemed to heading towards adopting the very same approach.

We purposely don't call it the "uBlue paradigm" since it's not new

Fair enough, naming things is hard, but fully understood: the paradigm (and similar variants) have been around for some time; the application of the paradigm for a Linux desktop environment was novel (at least to me!)

[castrojo]

some cursory reading of various material within Fedora and OSTree was that they seemed to heading towards adopting the very same approach.

Well we're not prescient either, I got the inside scoop on the direction at a conference from one of the authors so it was mostly a matter of figuring it out while the stuff is being heavily developed. We're kind of stuck building the bridge as we cross it. I'll be on the Fedora Podcast with one of them next month and I'll link it here with more backstory, the media page on the website has more video links, I go into detail with Brodie Robertson on a bunch of this.