[OpenAFS] Red Hat RPM packaging

[Derek Atkins]

Hi,

On Wed, September 3, 2014 12:40 pm, Dave Botsch wrote:
> 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.

I would add rpmfusion to this as well.  It's effectively the EPEL for
Fedora, and they also (IMHO) try very hard not to override base (fedora)
packages, again, so you don't hit broken dependencies.  I've been very
happy using rpmfusion on my systems and I can't think of any time I've hi=
t
an issue.

> ATRpms and others are really horrid about both of those.

+1000.  Do not, under ANY circumstances, use ATRpms.  Dependency Hell doe=
s
not begin to explain how bad you will be bitten.

Personally I've never heard of "ELRepo" until this message.  I'd avoid
RepoForge, I think RPMFusion does a much better job.

-derek

> 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.htm=
l>,
>> openafs.org would like to stop providing RPM packaging for Red Hat Lin=
ux
>> 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 t=
he
>> 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 n=
ot
>>      allow 3rd-party kernel modules
>>      <http://fedoraproject.org/wiki/Packaging:Guidelines#No_External_K=
ernel_Modules>.
>>      It is at least theoretically possible to just submit the server
>>      portions, and put the client bits elsewhere, but that seems reall=
y
>>      undesirable.
>>
>>  (2) ELRepo <http://elrepo.org/>. There already is a package here:
>>      <http://elrepo.org/tiki/kmod-openafs>, maintained (or at least, w=
as
>>      maintained) by Jack Neely. The only problem noted so far is that
>>      ELRepo uses something called kabi-tracking-kmods, which has cause=
d
>>      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 her=
e,
>>      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
> ********************************
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>


--=20
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant