[OpenAFS] Red Hat RPM packaging

[Andrew Deason]

As mentioned and discussed in this thread:
<https://lists.openafs.org/pipermail/openafs-info/2014-June/040734.html>,
openafs.org would like to stop providing RPM packaging for Red Hat Linux
distributions going forwards, to decouple upstream and downstream
development (as is done on Debian and others). Under that model, we'd
still continue to provide updated packages for RHEL6 and earlier, but
not for RHEL7 and on.

I thought we were intending to transition users towards packaging in the
3rd-party ELRepo service, but based on discussion in the release-team
meeting today, that doesn't seem like it is happening. In the absence of
a clear decision on what to do, I'm creating this thread soliciting
input from users on where they would like the Red Hat RPMs to live.

So, please say what would work best for you. If you would be able to
help with maintaining the packaging on any of these, also please speak
up. One single option may not work for everyone, but it would be nice to
not have everything scattered more than it needs to be.

Anyway, the options I am aware of are:

 (1) Fedora itself (and EPEL). Obviously this would be the most
     desirable, but we cannot use this for the client, since they do not
     allow 3rd-party kernel modules
     <http://fedoraproject.org/wiki/Packaging:Guidelines#No_External_Kernel_Modules>.
     It is at least theoretically possible to just submit the server
     portions, and put the client bits elsewhere, but that seems really
     undesirable.

 (2) ELRepo <http://elrepo.org/>. There already is a package here:
     <http://elrepo.org/tiki/kmod-openafs>, maintained (or at least, was
     maintained) by Jack Neely. The only problem noted so far is that
     ELRepo uses something called kabi-tracking-kmods, which has caused
     the client to break in the past (but I believe this is already an
     issue with existing RHEL6 packaging).
     
 (3) ATrpms <http://atrpms.net/>. There is some existing packaging here,
     but it's pretty old. I'm not aware of any issues with using this,
     but I wouldn't know.

 (4) Some other 3rd-party repo (RPMFusion? RepoForge?). I'm not aware of
     any issues with RPMFusion or RepoForge, but I wouldn't know, and I
     haven't seen any previous openafs packaging in there.
 
 (5) Keep the packages on openafs.org, exactly as they exist now. You
     need to manually install a new repository for every release (e.g.
     openafs-release-rhel-1.6.9-1.noarch.rpm).

 (6) Keep the packages on openafs.org, but use one repository for all
     releases.

If any of these choices are obviously better for your site, please say
something.

-- 
Andrew Deason
adeason@sinenomine.net