split "extra" kmods into distinct build flow #176
Comments
|
Thank you for pulling together the above summary and for chatting on discord (thread link for anyone interested), @bsherman! I have pulled together a draft PR at #163 and would appreciate your feedback. Please see below for a summary of the changes along with some potential todos:
The PR also includes my additions for the facetimehd-kmod, making it the first entry into "extra." I welcome any feedback the PR, approach, etc. Please also let me know if you prefer me to work on the other todo items within the same PR or keep separate? I didn't want to add too much or go too far down this path before getting feedback. You can get a preview of the build results in a separate PR on my fork here: mulderje#5 Is the above fork/build in the forks PR the best way for me to handle the build cycle within GH or is there a way for me to kick the PR here? edit: clarify question on build best practices at the end |
|
I took a moment to do an audit of the kmod packages that are being included in the Bazzite and Bluefin images. The below table pulls together a list of any package explicitly included via an Please take a look and let me know what you think. If you like the below break out I can either pull into the initial PR (#163) or hold off for the (potential) broader refactor I mentioned above. Package summary
|
This is looking great! I'm very thankful for you jumping in to help with this! It appears we are communicating well because this looks very much like I would have imagined.
I would prefer to keep adding new features separate from a restructuring of the build, it's just cleaner.
The approach you are taking with a PR in your fork is good. Thank you again. Related to a question in discord about PRs blocking your work on this:
As I said in Discord, I'm just a volunteer trying to find time around work and family, so mid-week efforts can be more challenging for me... that said... I don't want to be a blocker and #171 is the next thing on my TODO list. I'll assign you this issue and add it to our project tracker if you are cool with that. |
Love this audit! I'll give feedback on the specifics of which module goes where another time, as I know I would organize slightly differently, but that's easy to change.
Yes, this is pretty much what would happen fore Bazzite, or any other consumer of If we organize the way I expect, Bluefin won't actually be consuming |
Sounds good and agreed. I'll get started on drafting a PR for some of the refactoring (e.g. moving build files, building a post script, etc.) that should have no functionality changes. Will post a link here once I'm able to pull together.
Yep - sounds good! Just subscribed to #171 to keep track there; makes sense to hold off to me too. Let me know if there is anything I can do to lend a hand.
Sounds good. Thank you. |
|
Two quick updates here to lay the foundation for other refactors (also updated the list a few comments up). There is no intended functionality change for either of these PRs as of now, and both are passing builds in my fork.
Please note that depending on the merge order will need to rebase one of these to change the post script directory. |
FYI just did some updates to the table, marking a few more as common. I also added a few notes. Next up, I'll draft up a PR that puts this into a |
|
Happy Fedora 40 release day! I have gone through and updated the below package summary with some recent changes, and also rebased #163 to the latest main branch. Please give a shout with any questions/feedback. Package summary
|
Thanks! Here's the definition I've been imagined for the streams:
With that definition in mind, there are several currently marked as "common" in your chart's "stream" column which I think should be marked as extra. Also, |
|
Updated in #163 to reflect the below. I have also pushed ublue-os/bazzite#1009 to ensure we are adding in the additional
|
|
Thanks for the help getting this pushed! |
The more kmods we add to
Containerfile.commonthe longer builds take, and, the more likely we break downstream builds for Aurora/Bluefin and others.Specifically, there are a number of kmods which have been added which are only used in Bazzite. While these are good for us to build, Bazzite builds less frequently and is more actively than managed than some other downstream images.
I propose to add another "stream" of kmod builds to this repo so we'll have:
Containerfile.nvidia- as is, just builds nvidia kmodContainerfile.common- will build common/shared kmods (eg, those which were originally inmain:kmodsimages, and/or are used in both Aurora/Bluefin and Bazzite)Containerfile.extra- new addition will be primarily for kmods used in Bazzite or any others we need to build but don't fit incommonThe new
extracategory would NOT blog merge queues forakmodswhich would allow ourhweandbluefinbuilds to stay more reliable, even if we have somewhat experimental kmods inextra.The text was updated successfully, but these errors were encountered: