Proposal: reduce the scope of ublue-os/main images

[bsherman]

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
• 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.

Timeline

To minimize the impact on current users of our *-main images, these changes will go into effect with Fedora 39. Fedora 37 and 38 will continue to provide the *-nokmods images until their EOL in November and next May. Starting with Fedora 39, *-main images would exclude all kmods, focusing only on refinements to the base images.

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.

Addendum

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

Edits:

1. added Addendum with notes from @akdev1l
2. added Timeline per discussion with @EyeCantCU
3. removed "kernel-tools" from list of packages removed

[bsherman]

/vote

[git-vote]

Vote created

@bsherman has called for a vote on Proposal: reduce the scope of ublue-os/main images (#369).

The members of the following teams have binding votes:

Team
@ublue-os/approver

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 3days. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[bsherman]

FYI @ublue-os/approver

@EyeCantCU discussed and realized we did not specify timeline in this proposal. As such, I've added a timeline section clarifying this change will be for Fedora 39 forward. We'll maintain existing setup for Fedora 37 and 38.

[git-vote]

Vote closed

The vote passed! 🎉

71.43% of the users with binding vote were in favor (passing threshold: 66%).

Summary

In favor	Against	Abstain	Not voted
5	0	0	2

Binding votes (5)

User	Vote	Timestamp
@bsherman	In favor	2023-09-25 19:08:32.0 +00:00:00
@bigpod98	In favor	2023-09-25 21:29:20.0 +00:00:00
@marcoceppi	In favor	2023-09-27 22:58:07.0 +00:00:00
@EyeCantCU	In favor	2023-09-25 19:08:12.0 +00:00:00
@KyleGospo	In favor	2023-09-27 23:28:41.0 +00:00:00

Non-binding votes (8)

User	Vote	Timestamp
@fiftydinar	In favor	2023-09-25 19:20:14.0 +00:00:00
@xynydev	Abstain	2023-09-25 19:26:11.0 +00:00:00
@Zoialord	In favor	2023-09-25 21:19:09.0 +00:00:00
@castrojo	In favor	2023-09-25 21:21:23.0 +00:00:00
@Daredevil3869	In favor	2023-09-25 23:21:48.0 +00:00:00
@nicknamenamenick	In favor	2023-09-26 1:25:25.0 +00:00:00
@ArtikusHG	In favor	2023-09-26 6:14:55.0 +00:00:00
@MickSt	In favor	2023-09-28 13:19:45.0 +00:00:00

[castrojo]

Just to account for the bot missing this, I initially +0'ed and then changed it to +1 so that might be why I'm non-binding. So just leaving a comment for the record.

[bsherman]

@EyeCantCU and I will tag team on the implementation for this.

I'd like to have a number of PR's staged so we can roll out cleanly.

[EyeCantCU]

@EyeCantCU will tag team on the implementation for this.

I'd like to have a number of PR's staged so we can roll out cleanly.

Sounds great! Happy to get to work on this

[bsherman]

Another edit:

I discovered that kernel-tools is meant to be on all *-main images, even those which don't have kmods, so that has been corrected.

[castrojo]

[bsherman]

With the merging of #375 (and #390) ... the bulk of the work for this proposal has been completed.

main now does what was proposed. @EyeCantCU and I also reviewed the nvidia repo and believe it will "just work" as we'd anticipated.

[bsherman]

Website was also updated to add info about this to the main image section

[bsherman]

And... ASUS has had an update for this: ublue-os/asus#14

[castrojo]

Anything left to do or can we close this out?

[bsherman]

@EyeCantCU I think the last things related to this were Asus and Surface builds, which you got wrapped up, right?

[castrojo]

Ok @EyeCantCU says this is all done, what's the next step?

[EyeCantCU]

I believe this is all wrapped up :)

[bsherman]

I'm closing it. :-)