On 07/09/2014 12:44 PM, Stephan Wiesand wrote:
> On Jul 9, 2014, at 19:21 , Akemi Yagi wrote:
>
>> On Wed, Jul 9, 2014 at 9:52 AM, Stephan Wiesand <[log in to unmask]> wrote:
>>> On Jul 7, 2014, at 20:25 , Akemi Yagi wrote:
>>>> 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.
>> The maintainer of OpenAFS changed his job and no longer has the same
>> free time as he used to. In fact I have not hear back from him. At
>> this point, it looks as if you'd be the only person who can continue
>> doing the work for OpenAFS.
>
> There's actually another person within the OpenAFS project considering to step
> up as a maintainer of the ELRepo packages. But I believe this will also depend
> on the kernel module handling. So the answer to that question is really the key.
>
Hi Stephan,

Just circling back around here since there hasn't been a lot of further 
developments.

I'm going to attempt a quick summary of where I think the SL side of 
this is at, if I'm wrong do let me know:

1) For naming convention 'openafs16' sounds like a nice plan.

2) Using systemd units seems like the right integration point

3) Trusting your expertise

4) My thinking is that, if those are "optional" for first release lets 
leave them off.

5) Lets stick with the "SL6 kmod" system.  We've got in use now.


Pat

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/