Description of problem: EL7.1 comes with gcc = 4.8.3-9.el7, but dragonegg requires gcc = 0:4.8.2-16.2.el7_0 Version-Release number of selected component (if applicable): dragonegg-3.4-2.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Update to EL7.1 2. Try to install dragonegg Actual results: # yum install dragonegg Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * base: ftp.funet.fi * cr: ftp.funet.fi * epel: mirror.nsc.liu.se * extras: ftp.funet.fi * fasttrack: ftp.funet.fi * updates: ftp.funet.fi 452 packages excluded due to repository priority protections Resolving Dependencies --> Running transaction check ---> Package dragonegg.x86_64 0:3.4-2.el7 will be installed --> Processing Dependency: gcc = 4.8.2-16.2.el7_0 for package: dragonegg-3.4-2.el7.x86_64 --> Processing Dependency: libLLVM-3.4.so()(64bit) for package: dragonegg-3.4-2.el7.x86_64 --> Running transaction check ---> Package dragonegg.x86_64 0:3.4-2.el7 will be installed --> Processing Dependency: gcc = 4.8.2-16.2.el7_0 for package: dragonegg-3.4-2.el7.x86_64 ---> Package llvm-libs.x86_64 0:3.4.2-6.el7 will be installed --> Finished Dependency Resolution Error: Package: dragonegg-3.4-2.el7.x86_64 (epel) Requires: gcc = 4.8.2-16.2.el7_0 Installed: gcc-4.8.3-9.el7.x86_64 (@qacr) gcc = 4.8.2-16.el7 gcc = 4.8.3-9.el7 Available: gcc-4.8.2-16.el7.x86_64 (base) gcc = 4.8.2-16.el7 Available: gcc-4.8.2-16.2.el7_0.x86_64 (updates) gcc = 4.8.2-16.2.el7_0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Expected results: dragonegg should get installed
dragonegg-3.4-3.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/dragonegg-3.4-3.el7
Thanks for letting me know. As my request for an RHEL license for fixing and testing things like this was not approved, I usually can't deal with these kind of issues until the corresponding CentOS release is available. In this case that should be fairly soon, perhaps within days. However, since you provided the full GCC release, I have updated the dragonegg spec appropriately and built it with koji, and will be pushing it to testing momentarily. Unfortunately I think that when the new package is pushed to stable, anyone still using EL 7.0 (or CentOS 7.0) will not be able to install dragonegg.
Thanks for the update. For what it's worth, 7.1 has been available through CR for two days now, http://lists.centos.org/pipermail/centos-announce/2015-March/020980.html
Package dragonegg-3.4-3.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing dragonegg-3.4-3.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1313/dragonegg-3.4-3.el7 then log in and leave karma (feedback).
From the update system: "As far as I can see, this package still requires gcc = 0:4.8.2-16.2.el7_0" OK, I guess I have no idea how to fix it. I could do a local build against CentOS 7.1, but official packages have to be built through koji. I built it with koji for the epel7 target, assuming that it would build against the latest release of EL (7.1), but it apparently still builds against 7.0. I'll ask on EPEL-devel, but I'd advise not holding your breath.
Looking at https://kojipkgs.fedoraproject.org/packages/dragonegg/3.4/3.el7/data/logs/x86_64/root.log it looks like gcc-4.8.3 was included in the buildroot, along with redhat-release-server 7.1. No idea why the built package still wants to require the old gcc.
dragonegg-3.4-4.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/dragonegg-3.4-4.el7
dragonegg-3.4-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.