Hi Pat,

On Mar 15, 2013, at 15:33 , Pat Riehecky <[log in to unmask]> wrote:

> On 03/15/2013 09:05 AM, Stephan Wiesand wrote:
>> On Mar 15, 2013, at 14:19 , Pat Riehecky <[log in to unmask]> wrote:
>> 
>>> On 03/14/2013 04:56 PM, Schaaf, Jonathan P (GE Healthcare) wrote:
>>>> Hello everyone,
>>>> 
>>>> The recent update to Open AFS (kmod-openafs-1.6.2-4.SL64.el6.noarch.rpm) has dependencies on two kmod packages, which ultimately creates a dependency on two kernels.  I'm just curious whether this was intentional or inadvertent.  If intentional, why two kernels?
>>>> 
>>>> Thanks,
>>>> 
>>>> Jonathan
>>> The package depends on the '6.4' kernel and a '6.3' kernel.  The goal here was to make it simple to downgrade from the 6.4 kernel to the 6.3 kernel if you find issues with the newer kernel.
>>> 
>>> The basic idea was, if you want to downgrade kernels you shouldn't have to do any extra magic to get OpenAFS to work.  This comes at the expense of an extra kernel, but the alternatives would require far more end user work for something that 'just worked' on 6.3 and earlier.
>> 
>> I don't think we intended to force in the additional kernel. In the current situation this happens because we left the KABI dependencies in the kmod-openafs-<nnn> packages, and the KABI hashes required by the OpenAFS module changes between 6.3 and 6.4 kernels - for the first time since SL6.0 GA.
>> 
>> We probably should make kmod-openafs depend only on the latest kmod-openafs-<nnn> . Pat, if we don't make this change, both a 6.3 kernel and the module will also have to be in the 6.4 tree, which is kind of ugly, or you won't be able to actually install the client. It's a very cheap change, too. Anything but kernel downgrades would still work as intended.
>> 
>> Alternatively, we can rip out the KABI dependencies. We'd still install both modules, but no longer force in a whole kernel. On the downside, we'd rip out the compatibility checks too. As we had to learn, they're not perfect, but better than nothing.
>> 
>> 
>> 
>> Regards,
>> 	Stephan
>> 
> 
> Hi Stephan,
> 
> I've got the one in the 6.4 tree updated to just depend on kmod-openafs-358.

great.

Kernel downgrades are a corner case, and you have to do things manually anyway. Kernel updates should work fine since the old module isn't replaced - once the "new" packages are installed.

It is this one time, where we switch from the old to the new packaging, that it could happen that after a kernel update there is no longer an openafs module installed for the currently running kernel. The running client will of course continue to work, but restarting it won't. But now that the update was out there for a while, most systems won't have that problem.

> The kabi change with 6.4 was unexpected and may have made this machinery unnecessary.  It may prove handy for 6.5 though.

The machinery still makes sense, I believe. Yes, it should avoid these problems for future updates. And we have a lot more control and ways to deal with unexpected situations, like, say, a change in the non-whitelisted part of the KABI used by the openafs module. There is no guarantee that this won't happen.

Regards,
	Stephan

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15732 Zeuthen, Germany