On 12/19/20 4:39 PM, Phil Perry wrote: > Many of our own drivers will require a code rebase for each rebuild or > patches updating that no longer apply cleanly. This is not something > that can be readily automated. Secondly, as I understand it, as we > move forward and Red Hat kernel development moves towards the CentOS > Stream model, we will be seeing nightly builds so this work will need > to be undertaken on a daily basis which again is simply not feasible, > nor sustainable. Even if we could rebuild our content on a daily > basis, by the time we've updated our build systems with the latest > CentOS Stream kernel, rebased , fixed and rebuilt 50+ packages, signed > them, put them through QA and released them, and our global mirror > network has synced, CentOS Stream will have likely released the next > daily kernel update and we are back to square one. What are your thoughts on publishing a "kernel" repo that includes not only the 3rd party modules, but the kernel as well? CentOS Stream users who need 3rd party modules could blacklist kernel packages from the primary repos, and get both kernels and modules from the elrepo kernel repository. If the RHEL kernel release cadence is the target that you think elrepo can support, then you could rebuild the RHEL kernel srpm rather than a CentOS Stream one (or use the Stream package that eventually makes it into an RHEL release). I think you'd be able to continue supporting both RHEL and CentOS Stream with a single repo by rebuilding one more package.