[OpenAFS] Red Hat RPM packaging
Wed, 03 Sep 2014 14:00:43 -0400
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" <firstname.lastname@example.org> wrote:
> 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 =
> an issue.
> > ATRpms and others are really horrid about both of those.
> +1000. Do not, under ANY circumstances, use ATRpms. Dependency Hell d=
> 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.
> > 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=
> >> openafs.org would like to stop providing RPM packaging for Red Hat L=
> >> distributions going forwards, to decouple upstream and downstream
> >> development (as is done on Debian and others). Under that model, we'=
> >> still continue to provide updated packages for RHEL6 and earlier, bu=
> >> not for RHEL7 and on.
> >> I thought we were intending to transition users towards packaging in=
> >> 3rd-party ELRepo service, but based on discussion in the release-tea=
> >> meeting today, that doesn't seem like it is happening. In the absenc=
> >> 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=
> >> up. One single option may not work for everyone, but it would be nic=
> >> 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=
> >> allow 3rd-party kernel modules
> >> =20
> >> It is at least theoretically possible to just submit the server
> >> portions, and put the client bits elsewhere, but that seems rea=
> >> undesirable.
> >> (2) ELRepo <http://elrepo.org/>. There already is a package here:
> >> <http://elrepo.org/tiki/kmod-openafs>, maintained (or at least,=
> >> maintained) by Jack Neely. The only problem noted so far is tha=
> >> ELRepo uses something called kabi-tracking-kmods, which has cau=
> >> the client to break in the past (but I believe this is already =
> >> issue with existing RHEL6 packaging).
> >> (3) ATrpms <http://atrpms.net/>. There is some existing packaging h=
> >> but it's pretty old. I'm not aware of any issues with using thi=
> >> but I wouldn't know.
> >> (4) Some other 3rd-party repo (RPMFusion? RepoForge?). I'm not awar=
> >> any issues with RPMFusion or RepoForge, but I wouldn't know, an=
> >> haven't seen any previous openafs packaging in there.
> >> (5) Keep the packages on openafs.org, exactly as they exist now. Yo=
> >> need to manually install a new repository for every release (e.=
> >> openafs-release-rhel-1.6.9-1.noarch.rpm).
> >> (6) Keep the packages on openafs.org, but use one repository for al=
> >> releases.
> >> If any of these choices are obviously better for your site, please s=
> >> something.
> >> --
> >> Andrew Deason
> >> email@example.com
> >> _______________________________________________
> >> OpenAFS-info mailing list
> >> OpenAFSfirstname.lastname@example.org
> >> https://lists.openafs.org/mailman/listinfo/openafs-info
> > --
> > ********************************
> > David William Botsch
> > Programmer/Analyst
> > @CNFComputing
> > email@example.com
> > ********************************
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFSfirstname.lastname@example.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> Derek Atkins 617-623-3745
> email@example.com www.ihtfp.com
> Computer and Internet Security Consultant
> OpenAFS-info mailing list