[CentOS-devel] openafs status?

[Manuel Wolfshant]

On 08/16/2015 12:41 AM, 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?
>
Each RHEL / CentOS kernel has kernel symbols whose values are preserved 
at least during the life or a minor release, usually for longer ( if not 
for the whole life ).
Correctly built kmod packages (and those from ElRepo are an example but 
some are also in the distro itself ) are built against a certain known 
good kernel whose kabi symbols will be required ( and checked ) at 
install time of said kmod. If the symbols do not match, yum will refuse 
to install the kmod.
I hope this answers your question.


As of preserving old kmods in the repo ... as long as they are not 
explicitly deleted, the kmods exist in the repo. I fail to understand 
the " 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. " sentence. Build 
your kmod correctly and it will work with future kernel packages without 
problems... at least until RHEL decides to change one of the kabi 
symbols ( which , as I said, only happens when a new minor release of 
the distro is launched ).