On Sat, Dec 19, 2020 at 4:40 PM Phil Perry <pperry at elrepo.org> wrote: > I fear this is not really practicable. 3rd Party kernel driver updates > are largely delivered for RHEL using Red Hat's Driver Update Programme > framework that has existed since the early days of RHEL5 [1-4]. It is > totally dependent upon the relatively stable kABI that exists in RHEL > between point releases. CentOS Stream does not provide this. You are > proposing we try banging a square peg into a round hole. As it stands, > CentOS Stream is great as a CI development system for us to use to > develop packages for the next point release of RHEL (e.g, 8.4), not for > us to develop packages intended to be consumed today by users running > Stream. Hi Phil, Yes, it's pretty clear to all that we're going to need to develop new mechanisms to make this work. > The solution is to make regular RHEL kernel updates available in the > Stream repository, on either an opt-in or opt-out basis, depending upon > one's intended use case. To suggest that a SIG or other mechanism could > be implemented to regularly rebuild 3rd party content is simply not > feasible for a number of reasons. Firstly, it's not simply a matter of > rebuilding 3rd party drivers against each newer kernel. 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. Square peg, round hole. Stream kernels + third party driver adaption logistics are complicated, but I don't think they're impossible. We probably have a different understanding of the constants and the variables in this equation, so let's keep talking about it and see what we can do. Again, a lot of Red Hatters are going to be absent the next couple weeks, but that's just bad timing, not disinterest. > I am encouraged that people within Red Hat are starting to recognise and > acknowledge some of the challenges we face, but the conversation seems > to be stuck at the same place and we are not moving forward to discuss > and implement the very workable solution which has been proposed. Can > regular RHEL kernels be populated into a Stream repository, either by > default or as an optional add on? If so, when can we expect this to happen? My reading of Q14 on https://centos.org/distro-faq/ suggests this would not be allowed. > Or maybe Red Hat's solution is for any affected CentOS Stream customers > to email centos-questions at redhat.com and be given free RHEL licenses? It > would be nice to have some clarity around this. Whether you're blocked from using CentOS Stream or RHEL, we definitely want to hear the details, so we can make one or both viable options. -- Brendan Conoboy / Linux Project Lead / Red Hat, Inc.