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/