[OpenAFS] Red Hat RPM packaging
Wed, 3 Sep 2014 11:03:45 -0500
As mentioned and discussed in this thread:
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
It is at least theoretically possible to just submit the server
portions, and put the client bits elsewhere, but that seems really
(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.
(6) Keep the packages on openafs.org, but use one repository for all
If any of these choices are obviously better for your site, please say