On Jul 7, 2014, at 20:25 , Akemi Yagi wrote:

> On Mon, Jul 7, 2014 at 7:07 AM, Pat Riehecky <[log in to unmask]> wrote:
>> On 07/04/2014 12:22 PM, Stephan Wiesand wrote:
>>> 
>>> I think there are some questions we should answer before choosing or going
>>> to work:
>>> 
>>> 1) If SL7 will have it's own packaging, should the packages renamed to
>>> something like "openafs16" or even "openafs16-sl"? I think that's a good
>>> idea, for two reasons: It avoids clashes or even inadvertent mixing with
>>> other packages like the ELrepo ones, and it would allow us to provide
>>> OpenAFS 1.8 (likely the next stable series) packages eventually, without
>>> forcing such a significant update on sites in the middle of a major SL
>>> release cycle.
>> 
>> I see where you are headed here, and it is interesting.  I'll let others add
>> their thoughts, but this sounds like a viable approach. I know we've got a
>> few ELRepo folks on the list.  If we can find a way to reduce everyone's
>> over all labour here that would be great! We may have to take that to the
>> elrepo list for full exposure there.
> 
> Speaking as a person from ELRepo... I think it's a great idea to
> combine the efforts. However, at this point in time, I'm not sure if
> our (ELRepo's) OpenAFS maintainer has the time for EL7. I need to ask
> him.


Combining the efforts would be great. I'm not even sure you actually have
a maintainer for your OpenAFS packages right now though ;-)

And there's a major obstacle: The OpenAFS developers and experts are quite
violently opposed to using "kabi-tracking kmods" with OpenAFS. In fact,
they'd make it impossible if they could. And these kmods are actually known to
have been broken due to kernel changes between EL minor releases. Luckily, in
a way that won't silently corrupt data at least on our SL6 clients. What we're
doing on SL6 now (modified scripting to reuse a module for kernels
corresponding to the same minor EL release only) is a compromise I consider
just about acceptable. The plain weak-updates ELRepo is using isn't.

Would ELRepo accept any other way of packaging the OpenAFS kernel module?

My proposal above would really just make coexistence of different SL and
ELRepo (and other) packaging for OpenAFS more peaceful and easier to handle
for users. If we can achieve more, that would indeed be great.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany