[OpenAFS] Red Hat RPM packaging

[Dave B]

The old Dag repo was also horrible w overrides & deps. I think it got=20
merged w some others, so not sure of the current state of it.

For EL, maybe CentOS repos make sense?


On September 3, 2014 1:53:03 PM "Derek Atkins" <derek@ihtfp.com> wrote:

> 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 =
hit
> an issue.
>
> > ATRpms and others are really horrid about both of those.
>
> +1000.  Do not, under ANY circumstances, use ATRpms.  Dependency Hell d=
oes
> 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.h=
tml>,
> >> openafs.org would like to stop providing RPM packaging for Red Hat L=
inux
> >> 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, bu=
t
> >> 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-tea=
m
> >> meeting today, that doesn't seem like it is happening. In the absenc=
e 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 spe=
ak
> >> up. One single option may not work for everyone, but it would be nic=
e 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
> >>     =20
> <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 rea=
lly
> >>      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 tha=
t
> >>      ELRepo uses something called kabi-tracking-kmods, which has cau=
sed
> >>      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 h=
ere,
> >>      but it's pretty old. I'm not aware of any issues with using thi=
s,
> >>      but I wouldn't know.
> >>
> >>  (4) Some other 3rd-party repo (RPMFusion? RepoForge?). I'm not awar=
e of
> >>      any issues with RPMFusion or RepoForge, but I wouldn't know, an=
d I
> >>      haven't seen any previous openafs packaging in there.
> >>
> >>  (5) Keep the packages on openafs.org, exactly as they exist now. Yo=
u
> >>      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 al=
l
> >>      releases.
> >>
> >> If any of these choices are obviously better for your site, please s=
ay
> >> 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
> >
>
>
> --
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info