On 19/12/2020 22.42, Brendan Conoboy wrote: > On Sat, Dec 19, 2020 at 1:13 AM Peter Georg > <peter.georg at physik.uni-regensburg.de> wrote: >> On 19/12/2020 07.44, Karsten Wade wrote: >> I agree with you that CentOS Stream might actually be a good way forward >> and consider (even looking forward to) switching from CentOS Linux to >> CentOS Stream for the reasons you mentioned. >> However I disagree on one point: You mention CentOS Stream can cover >> "95% (or so)" of the current users. As long as 3rd party drivers are not >> working with CentOS Stream the number will be lower. >> This topic has already been mentioned several times on this mailing list >> by various users. So far feedback has been positive here on the list. >> >> In my opinion, the only way to guarantee compatibility is by 100% kernel >> ABI compatibility. The only way I can think of implementing this is by >> offering an optional "RHEL kernel repository" containing the (updated) >> kernel of the current RHEL minor release. Feedback to this proposal has >> been positive so far as well, but no concrete feedback yet. >> I even suggested this to centos-questions at redhat.com. So far I only got >> a response that I shall wait till next year for no- and low-cost RHEL >> offerings. Let's wait and see if I get a useful answer to my proposal. >> >> Sorry for mentioning this issue once again here on the mailing list, but >> I just hope that by mentioning it often enough, the possibility of this >> issue/proposal being acknowledged goes up. > > Hi Peter, > > Thanks for mentioning it again- I would encourage anybody else who is > using kernel modules that aren't included in the stock kernel to mail > centos-questions at redhat.com and let us know about it. Thanks for your support! > > Just on list I've read that the ongoing ability to use CentOSPlus, > ELRepo, and a few miscellaneous third party drivers is the difference > between being able to adopt CentOS Stream or not. My impression is > that if CentOS Stream can provide some mechanism by which people will > be unable to 'dnf update' their way into an unusable system for want > of a compatible kernel module, that somewhat resolves the issue. I > picture a SIG being formed of community members to create this and > oversee the multiple implementation details that would be necessary > per use case (EG, don't stop ELRepo, provide something that works > smoothly with it). I think it is not enough to provide "some mechanism by which people will be unable to 'dnf update' their way into an unusable system" due to incompatible kernel module is enough. One also needs to be able to install a new system with a particular kernel version x that works with a 3rd party driver. This could be solved by keeping all ever released kernel version in the repository. To reduce the amount of kernel versions to store, I suggested to limit it to the version provided by the most recent minor release. In addition the kernel version provided in a minor release might also be updated to fix security issues etc. These retain kABI compatibility (at least in most cases) to the "base" minor release version. These kernel versions are not available in CentOS Stream at any time. Hence my suggestion has been to introduce a "RHEL kernel" repository that provides the current RHEL minor releases' kernel (and directly dependent RPMs). Whenever there is an update to the minor release's kernel (without changing the RHEL minor release), this version will be added to the "RHEL kernel" repository. I.e., versions 4.18.0-x.y, which are never being released for CentOS Stream. Once a new RHEL minor release is available, the "RHEL kernel" repository is moved to vault (or deleted?) and we re-start with an empty "RHEL kernel" repository. We will then add the new RHEL minor release's kernel. This explanation is somewhat complicated and a simpler, but maybe more controversal, explanation might just describe the suggested "RHEL kernel" repository as "CentOS Linux limited to the kernel (and directly dependent) packages". > > Coincidentally, for anybody who uses the word "stable" or "unstable", > it's always helpful when you outline what you mean by that. I'm > personally aware of 4 different meanings, and suspect at least 2 more > are being used here! This is a good practice for both on-list > discussions and reports to centos-questions at redhat.com. > > Finally, I want to mention that a number of Red Hatters are now or > about to be on an end of year holiday. Consequently, some people who > would normally be joining in constructive conversations are away from > their email. Please nobody take this as a lack of interest or > concern, they'll be back bright and early next year. >