Stephan Wiesand wrote:
> Hi All,
> 
> I put up a first proposal: http://www.ifh.de/~wiesand/SL6/openafs.SLx-1.5.78-86.src.rpm
> 
> Build instructions are in the package description, and the changelog should be fairly complete. The major changes with respect to our current 1.4 packages are:
> 
> 1) It's openafs-1.5.
> 
> While 1.4 is still the "stable version", it will soon be superseded by 1.6 (which is what will become of 1.5). A 1.6 release candidate is expected "real soon now". The 1.5 client has been usable and stable for a while. What's been delaying the release is the server side (in particular, the "Demand Attach" Fileserver). For SL6, we should not settle for an openafs release that will be considered legacy very soon. The 1.5 client has been doing very well on all our "SL6" (RHEL6 beta/beta2/beta2refresh/GA/SLalpha<n>) systems. And it builds on SL6 without having to be patched, while the latest 1.4 client (1.4.12.1) still has.
> 
> Falling back to 1.4, if we really had to, would be rather straightforward.
> 

I'm good with openafs 1.5, no complaints here.

> 2) The default cache location moved from /var/cache/openafs to /var/cache/afs.
> 
> That's because on SL6 with SELinux enabled, the client is governed by the targeted policy. That's a good thing. But it also means we either have to stick with what the policy supports, or [have our users] jump through extra hoops. And the policy supports having the cache in /var/cache/afs or /usr/vice/cache, but not in /var/cache/openafs.
> 

We'll have to document this, but that's not too hard.

> 3) Support for SL3/4 was removed. The SRPM only works on SL5/6.
> 
> This allowed for a major simplification of the spec file. SL4 support could be retrofitted with (quite) a bit of work, but would also complicate the spec significantly. Given the limited TTL of SL4 (~ 1 year), I left it out for the time being.
> 

No complaints here.
I assume that a openafs 1.4 client can connect to a 1.5/1.6 server.

> 4) The openafs-debug package was renamed to openafs-plumbing-tools.
> 
> Suggestions for better names are welcome.
> 

I'm curious about this change.
All of the packages in this rpm have debug in the name, except 
state_analyzer.  Why the name change?

> 5) It builds KABI-dependent kmod-openafs packages.
> 
> While the ability to build our traditional kernel-module-`uname -r` packages is still there (and required on SL5, I think, because KABI tracking kmods make little sense there for openafs), this is probably the way to go for packaging the kernel module on SL6 and beyond.
> 
> As in the past, simply rebuilding the SRPM will give you all the userland packages, specifying "--define build_modules 1" will give you the kernel-module-package instead, and specifying "--define kernel '<uname -r output on target system>'" in addition allows defining the kernel to build the module against.
> 
> When "--define 'build_modules 1'" is replaced by "--define 'build_kmod 1'", a KABI-dependent package kmod-openafs is built instead, making use of /sbin/weak-modules to register the module as a "weak update" for all kernels (installed now or in the future) with a compatible ABI. Up to EL5, only the "whitelisted" ABI was exported as "Provides:" by the kernel package, making it problematic to use this mechanism for modules using non-whitelisted interfaces. And the openafs module uses a lot of them. But since EL6, the whole ABI is exported, hence it starts making sense to use this mechanism.
> 
> The advantage: as long as the KABI is stable, there's no need to update the kernel module package when updating the kernel. The module will simply be symlinked into /lib/modules/<new kernel>/weak-updates of any kernel with a compatible ABI. Often, this will make an update of the kernel module package unnecessary. And no need for a yum plugin.
> 
> The disadvantage: *if* the KABI changes with a kernel update:
>  o an update of kmod-openafs is required to have a working client for the new client
>  o as soon as kmod-openafs was updated, there's no more working module for earlier kernels installed
> 
> In the latter case, even "service afs restart" is bound to fail. Unfortunately, this is likely to happen. The openafs module is using many interfaces that aren't whitelisted. Many of those changed from beta2 refresh to GA. The build for the GA kernel (71.el6) works fine on the zero-day update (71.7.1.el6) though.
> 
> 
> When implementing those kmods, I started out from what the elrepo folks are doing, but made a few significant changes. Any comments are very welcome:
> 
> o there's a single spec for the userland/kernel-module/kmod packages
> o a -debuginfo package is built (taking care the name makes sense)
> o weak-modules is called with the --no-initramfs switch
> o an abbreviated form of the kernel release is appended to the kmod-openafs package release
> 
> The last change was made because I just couldn't stand it that the SRPM could be rebuilt against a different kernel (possibly with an incompatible ABI), resulting in packages with exactly the same n-v-r but very different content. And to avoid the need to touch the spec every time modules for a new kernel are rolled out. So what happens is that the release part of the target kernel's `uname -r`, without the gratuitous architecture and the dist tag, is appended to the kmod's release. This allows for clean updates when the module is built for a later kernel, and to install the right debuginfo package if you have to. But it's different from elrepo.
> 
> 
> I tested quite a bit with these packages, and wasn't able to break them. Using rpm, not yum, they can even be coinstalled, providing usable modules for their respective kernels. The weak-modules script is handling everything I can throw at it right now. I couldn't test how it behaves if there's more than a single other kernel with a compatible ABI and kmod-packages are installed for all of them, though.
> 

This is possibly the greatest part of this source rpm.  Thank you for 
making an rpm that is able to do both the old and new way.  I know it's 
a lot of work.

> 6) The general aim is to make the SL packages more compatible with the openafs.org ones. As compatible as possible. Identical, if possible. The proposed SRPM already reflects this by moving files into the same subpackage as the openafs.org spec where it makes sense, building with the same compiler flags etc. I'm also going to work with the openafs.org folks (by submitting patches to their SCM) to make things more consistent from both ends. But that's going to take a while, and for SL6 we'll have to take decisions:
> 
> The next step in making things more compatible would be to rename the init/sysconfig files:
> 
> o /etc/init.d/afs        would become /etc/init.d/openafs-client
> o /etc/init.d/afs-server would become /etc/init.d/openafs-server
> o /etc/sysconfig/afs     would become /etc/sysconfig/openafs
> 
> And then, the content of those would have to be synchronized. Which would basically mean throwing away most of what we have today (automatic cache size, automatic home cell if it's the DNS domain, ...).
> 
> So the question is what's more important to our users: backward compatibility with previous SL releases, or compatibility with openafs.org. Any input?
> 

If we are going to do it (come in line with openafs.org) then now is the 
time to do it.
We can always tell our users it is a result of upgrading from 1.4 to 
1.5/1.6.  Most users are used to some changes that come about because of 
a major release update.

This might mean that we make a few SL_ rpm's that users can install so 
that AFS behaves the way it used to.

> Best regards,
> 	Stephan
> 

Thank you very much for all this work Stephan.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________