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]