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.

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.

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

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?

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.

And we should use the correct path to depmod, but that probably won't need discussion.

Any feedback most welcome,
	Stephan

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