On Monday, December 28, 2020 5:43 AM, Phil Perry <pperry at elrepo.org> wrote: > On 28/12/2020 08:02, Alexander Bokovoy wrote: > > > On su, 27 joulu 2020, Gordon Messmer wrote: > > > > > On 12/27/20 4:31 PM, Ljubomir Ljubojevic wrote: > > > > > > > On 12/27/20 5:00 PM, Alexander Bokovoy wrote: > > > > > > > > > I can see two major ways of enabling 3rd-party drivers: > > > > >  - using elrepo's excellent work on kmods to build a CI for CentOS > > > > >   Stream kernel updates and perhaps block updates based on CI > > > > > results' > > > > >   consensus (not necessary blocked until it 100% green) > > > > > Phil Perry from ElRepo project wrote extensively both on [CentOS] and > > > > > [CentOS-devel] lists why that aproach is not viable. > > > > > > I might be misreading one party or another, but I believe that what is > > > being proposed is better integration of ELRepo's kmod packages and > > > CentOS Stream, so that kernel updates aren't published until the > > > modules build. And if it is, then I'm not sure why that approach > > > would not be viable. > > > Neal Gompa wrote: "The correct fix here is to start blocking RHEL > > > kernel updates > > > against third-party Free Software kernel module packages to ensure > > > compatibility isn't broken and the kernel ABI stops breaking on every > > > kernel version series. The reason it keeps breaking is because there's > > > no current mechanism in which these are tested together to validate > > > them for release." > > > That seems like an ideal solution. > > > > You are getting it right, Gordon, thank you for connecting the threads. > > So if I understand correctly, the proposal is that if a 3rd party > (elrepo or OEM) driver does not build against a Stream kernel, you would > not release the kernel? That would mean to date there would not be any > Stream kernel updates released[1] because something breaks against > all of them? Or have I misunderstood what is being proposed? That > would be a real shame for those folks who would like to test new > functionality and/or participate and feed back in the development process. If I understand correctly, the kernel would still be released but be blacklisted from being installed by dnf on some systems. Almost like a subscription based extension to RPM driver metadata to add a Conflict line after the fact to a driver package. Then dnf would process the Conflict accordingly despite it have never existed at the time the driver package was originally released. I'm not sure how well such a system would be maintained. The inability to rollback is still a serious problem. It also could create another problem forcing users to decide the best of two evil. They could continue to use their driver or they could continue to get security patches but not both. It would be nice if driver conflicts was delt with at a more ganular level than allow or deny an entire kernel release. If release 249 worked fine and 250 doesn't, then as the upstream provider the Stream community should be able to look into the issue on a patch by patch basis. If release 250 has a security patch and a bugfix patch, it would be nice to see if the security patch can still be used with the driver. Instead, I believe what is purposed would blacklist the security patch as well just because it is bundled with a bugfix which is incompatible. I would consider such a purposal flawed.