On 07/04/2014 12:22 PM, Stephan Wiesand wrote:
>  From the SL7.0 alpha announcement:
>
>> This ALPHA does not include many historic SL addons.
>>
>> We would like to open discussion on which specific packages/utilities should be added to SL 7.
>>
>> Specific topics of conversation:
>> - OpenAFS
>>    We are interested in OpenAFS for SL7
> I'd be willing to care for openafs packaging for SL7, unless you'd rather have someone else maintain is, or use something else.

As our resident OpenAFS expert and OpenAFS project member, I'd love it 
if you cared for these packages.  I didn't want to volunteer you, but if 
you're interested, please!

>
> 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.

>
> 2) Should we use proper systemd unit files rather than sysvinit scripts on SL7? I think we should.

Personally, I'd much rather the systemd unit files.  I'm prepared to 
assist with that task if needed.  Several packages provide a 'legacy' 
sysvinit package with the older script (acpid, at, 
device-mapper-multipath, iputils, lvm2, net-snmp, openssh-server, 
postfix, sendmail, squid, vsftpd).  It might be advisable to do the same 
for OpenAFS.  I'd prefer to leverage as many capabilities of the new 
init system as possible, but I understand that not everyone is ready to 
jump.  Thoughts?

>
> 3) Do we want to stick with Transarc paths (=maximum backward compatibility) or move to FHS paths? I'm indifferent here.
>
> 4) Should we continue to ship kaserver and klog on SL7?

I don't know enough about these to answer them with any confidence. Is 
#4 is the server parts of AFS?

>
> 5) Should we continue to handle the kernel modules the way we do on SL6? What we're doing there is way better than "standard kmods" IMO, but let's not forget that all the experts really knowledgeable about the openafs module's inner workings still recommend building for each end every kernel.

I strongly prefer kmods.  My experience is that they result in much 
cleaner systems overall - YMMV.  I've mixed feelings about or SL6 
kmods.  On the one hand the kmod per minor release fixed a real bug that 
we hit.  Its hard to discount that.  On the other, There is some extra 
complexity from the rpms themselves.  With the separated rpm it also 
makes repoclosure complain unnecessarily.  I've got that last one fixed 
on our end with some simple excludes.

That entire paragraph to say, I'm not sure which kmod strategy is least 
confusing for end users, has the fewest pieces, and is least likely to 
break.  I may be over thinking this.....

>
> And we should use the correct path to depmod, but that probably won't need discussion.
>
> Any feedback most welcome,
> 	Stephan
>


-- 
Pat Riehecky

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