On 07/16/2014 03:28 PM, Pat Riehecky wrote:
> 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
>
For secure boot kmods, it looks like there may be some odd work to be
done....
I was pointed here for an example:
https://messinet.com/rpms/browser/dahdi-linux-kmod/dahdi-linux-kmod.spec
Pat
--
Pat Riehecky
Scientific Linux developer
http://www.scientificlinux.org/
|
