On 20/12/2020 22:40, Gordon Messmer wrote: > 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. > Yes, it is the RHEL kernel(s) that are required and a separate kernel repository is exactly what I've been requesting, on either an opt-in or opt-out basis. Technically, rebuilding the RHEL kernel(s) is not something that is difficult to do, but this is something I would really like to see Red Hat / CentOS make available as part of Stream since a wider need for it has been identified. This is something that has been repeatedly requested. It's a really small concession that is a really big deal to any potential CentOS Stream users reliant on 3rd party drivers. It is something I would have liked to have seen the CentOS board negotiate as part of the discussions, but as these all occurred behind closed doors, without any prior knowledge of or consultation with the community, it was not possible to highlight such issues in advance or have any input into those discussions. This is not a difficult thing for Red Hat to fix if they have the will. Lets give the folks at Red Hat / CentOS time to offer up some solutions. If Red Hat are unable to provide a solution, then it becomes a simple logistical issue for users to pull in the kernels that will exist as part of other community rebuild projects (e.g, to run a Rocky or whatever kernel on Stream).