[OpenAFS] Red Hat RPM packaging

[Dave Botsch]

I would vote either for openafs.org or EPEL .

EPEL is really good about making sure that they don't override base
redhat packages and that packages in the repo don't brake w.r.t.
dependencies.

ATRpms and others are really horrid about both of those.

On Wed, Sep 03, 2014 at 11:03:45AM -0500, Andrew Deason wrote:
> 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
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
********************************
David William Botsch
Programmer/Analyst
@CNFComputing
botsch@cnf.cornell.edu
********************************