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, d...@wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
