[CentOS-devel] openafs status?

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.