On Thu, 8 Jul 2010, Troy Dawson wrote:

> Dag Wieers wrote:
>>  On Thu, 8 Jul 2010, Troy Dawson wrote:
>> 
>> >  With many minor releases, we update the version of openafs for that 
>> >  minor release.  This new version then get's pushed out to the rest of 
>> >  the releases.
>> >  With SL 5.5 we updated openafs to 1.4.12, and we are about to push that 
>> >  version out to the rest of the SL5 releases.  It currently is in 
>> >  testing, and it has passed every updating test I could think to throw at 
>> >  it and it updated without any problems.
>> > 
>> >  We plan on pushing this out on Monday - 12 July 2010
>> > 
>> >  To test or update
>> > 
>> >  SL5
>> >  -------
>> > 
>> >        yum --enablerepo=sl-testing update kernel-module-openafs\*
>> > 
>> >  or you can download rpm's by hand at
>> > 
>> > http:  //ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/
>> > http:  //ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/
>>
>>  Would there be any interest if we provided kmod-openafs modules that are
>>  kernel-agnostic (or kABI-tracking as we say) from ELRepo ?
>>
>>  The advantage is that the modules keep on working through kernel-updates,
>>  which makes update-cycles (and maintenance) to be less work.
>>
>>  I am tempted to create those packages, but without an interested party
>>  that can provide sufficient testing the effort is kinda moot.
>>
>>  Let me know,
>
> I thought that the openafs kernel modules didn't work well with kABI, but I 
> would love to find that incorrect.  If you think it is possible, please build 
> it, and I'm certain we'll have plenty of testers.

If that is true we might have a discussion with Red Hat to see whether we 
can have those symbols as part of the kABI whitelist. Let's find out :-)


> For SL5, I'd like to stick with what we have with the supported release, but 
> I'm very sure that we would have plenty of users wiling to test and use the 
> kmod-openafs module.  If everything goes well, we could offer it as an 
> alternative.
>
> For SL6, if this works we could use that and save us from having to create 
> kernel modules with each kernel update.

Sure, I don't want to force anyone anyway. A clean upgrade path will be 
very hard due to the fact that these kernel-module packages have the 
kernel-version in the name. So your position makes a lot of sense.

-- 
--   dag wieers,  [log in to unmask],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]