Reduce the scope of ublue-os/main images

[castrojo]

^{Originally posted by bsherman September 25, 2023}

Summary

Revise scope of Universal Blue Main Images such that kmods (and associated kernel packages) are no longer included.

Description

The purpose of this change is to streamline build processes(current and future), maximize use of *-main images as a foundation for downstream efforts, and enable maximal flexibility for users running these images.

The primary change removes the following packages from *-main images:

• kernel-devel-matched
• kernel-tools
• kmods
  • xpadneo
  • xpad-noone
  • xone
  • openrazer
  • v4l2loopback
  • wl

Scope of Changes

• Main (repo)
  • Remove above packages from *-main builds
  • Stop building *-nokmods as those images will be identical to *-main after this change
• ASUS/Surface
  • Build directly from *-main
• Website
  • Clarify that *-main images should not include kmods, kernel-devel, kernel-tools packages
  • Emphasize that *-main may be used directly but is primarily a foundational part of the Universal Blue toolkit.
  • Better document use of akmods.
  • Announcement of change on Blog/Github/Discord

Not in scope

• Removal of *-nvidia images: they MUST have the nvidia kmod, so that will stay (still based on *-main so will lose the other kmods)

Benefits to Universal Blue

• Reduce complexity of builds and number of images maintained
• Provide a single foundational image for all downstream Universal Blue images/users
• Prevent artificial restrictions on downstream usage (kernel specific packages installed in *-main cannot be removed downstream or on a running system which prevents use as a base for images like asus/surface, any changes to kernel, as well as layering of related packages on running systems)

Feedback

A conversation in discord was had about narrowing the scope of our *-main images such that they no longer include kmods.

There were questions about impact to users of existing *-main images, the primary concern being removal of xpadneo and v4l2loopback as they are the two kmods which have existed for a longer time.

It was suggested we suggest users use *-nokmods images if they have issues with kmods in *-main, but that does not address the desire to simplify build processes within the Universal Blue organization.

Ways to address

We can suggest use of bazzite, bazzite-gnome or bluefin for users not wishing to build a custom image.

In the future, to partially offset the impact of these changes, just scripts may be implemented that simplify the installation of the kmods Universal Blue provides.

Other Thoughts

Hardware enablement has long been included in the scope of main images, but it was initially focused on the addition of udev rules, not the addition of kmods; those came later.

As of this writing, we have recently created *-nokmods because *-main's inclusion of a few kmods prevented it from being used as an upstream foundation for some downstreams needing a kernel swap, specifically *-asus and *-surface images.

Additionally, we recently discovered that that this longstanding bug was actually caused by the installation of kmods(and/or kernel-devel packages) in *-main images themselves.

These recent changes/discoveries and the increasing burden of managing image hierarchy are the primary motivators for narrowing the focus and "ripping the band-aid off" now, before things have a chance to become more complex.

Addendums

Impact of removing the kmods from main would be:

1. If a user is relying on such kmods upon an upgrade some their hardware may not work (rare) and additionally v4l2loopback will not be available for software that uses it to create virtual cameras (like OBS)

Impact of not doing this change is that:

1. Users who want to use main images but would rely on local akmod layering cannot easily use ublue as their locally layering will not work
2. Users who are using main images as base for their custom images will also have to add the kmods back if they want them or have the same behaviour as above
3. Users who want to create their own image with main as base but who also rely on kmods or custom kernels will be able to more easily set that up (currently they’d have to use the nokmods image as a workaround)

Above from @akdev1l : https://github.com/orgs/ublue-os/discussions/224#discussioncomment-7104856

Authors

• @bsherman
• @EyeCantCU

[bsherman]

how was that published in bazzite? LOL our discussions stuff is wonky

[castrojo]

I had to move it to bazzite to convert it to an issue and then moved it here. We should move proposals to just issues so we can vote directly from now on, but we can do that later.

Do a /vote on it's own line to kick off the voting, you can have the honors. EDIT: I've put 72h as the default voting period in the config.

[castrojo]

/vote

[git-vote]

There is already a vote in progress in this issue @castrojo.

Please wait until it is closed before creating a new one.

[castrojo]

Lol, copy and paste a new issue and we'll close this.

[bsherman]

Lol, copy and paste a new issue and we'll close this.

will do

[bsherman]

Please see: #369