On 08/15/2015 07:52 PM, Ned Slider wrote: > On 15/08/15 22:41, Jason Edgecombe wrote: >> On 08/15/2015 10:56 AM, Ned Slider wrote: >>> On 15/08/15 14:27, Jonathan Billings wrote: >>>> On Aug 15, 2015, at 9:10 AM, Jason Edgecombe >>>> <jason at rampaginggeek.com> wrote: >>>>> What's the plan for fixing CBS to accommodate this? If I had a spare >>>>> afternoon, what could I do to move this forward? >>>> Really, the end goal is to have the kmod-openafs packages built for >>>> every kernel release as it comes out, without removing the existing >>>> kmod-openafs from the repo. This is why I separated it out from the >>>> openafs spec/srpm, because it will need to be rebuilt every time >>>> there is a new kernel. However, OpenAFS users want to have >>>> historical kmods available. >>>> >>> Given that you really don't seemed to have moved forward in the last >>> year, I would reiterate what I said a year ago: >>> >>> http://lists.centos.org/pipermail/centos-devel/2014-September/012047.html >>> >>> I really don't understand why you would not want to use the framework >>> Red Hat provides to solve exactly this problem. You are trying to solve >>> a problem that is largely already solved. >>> >>> Worst case scenario is you'd need to rebuild kmod-openafs for major >>> point releases every 9-12 months (e.g, 6.5, 6.6, 6.7; and/or 7.0, 7.1, >>> ...) where the kABI is broken for non-whitelisted symbols used by >>> OpenAFS. That has to be a preferable solution for OpenAFS users than >>> rebuilding against each and every kernel release. >>> >> Does yum check and prevent or warn you when installing a kABI module for >> a non-matching kernel? How do I know which kmods match my kernel? >> > No, yum will only warn on symbols that may be missing, for example on > older kernels. > > Look to see if the module weak links against the kernel in the > corresponding weak-updates directory. > > Sometime a module can weak link but still not be compatible but it's > uncommon and only likely to happen when going from one point release to > another (e.g, 6.6 to 6.7) when Red Hat have changed the kABI of a > non-whitelisted symbol used by your module. Pre-release testing will > pick this up. Red Hat generally do not change the kABI within a point > release. A few folks in the OpenAFS community have been burned by the kABI and don't trust it, even for point RH releases. One gentleman was even burned by elrepo. Jason