No. The problem is the way the packages are built into .rpms. I’ve seen yum give up on stuff in the standard repos, because the manpages from a i386 package conflicted with the manpages from a package, sometimes the
*same* package… but that was the x86_64 version. The rules for the rpm install can specify (or not) whether to allow for this… but both epel and rpmfusion have packages compatible with the base, and seem to do pretty well with each other, while rpmforge doesn’t consider them.
The upshot is that a package will want, for example, a specific library that you *have*… but it was installed in package x.y.6, while the one from repoforge is expecting it to have come from *their* package q.j.6. The result is that it fails to install.
Is that any clearer?
mark
it helps a lot, if you set up all your repos with appropriate priorities right at the beginning. Or you can later on add a repo with a lower priority (so, higher priority= value). But even so, yum-priorities is not a magic bullet and there will be issues occasionally. And some choices will have to be made, by you the user. There’s no getting around that. In those cases priorities will usually tell you that there is a conflict, and you then make your decision and implement it (eg with excludes). Mark’s scenario falls into that category: libfoo v1.1 is installed from your high priority (HP) repo, but you want bar from the lower priority (LP) repo and bar requires libfoo v1.2, which is in the LP repo and mutually incompatible with v1.1. Then if you really want to install bar, you’ll have to exclude libfoo from the HP repo. That may prevent future package installs from HP, if they require the specific v1.1 version of libfoo.
repoforge/rpmforge/Dag has been a fantastic resource for ages, but today it’s pretty much dead in the water despite some good people trying to step in to help keep it afloat. Many thanks to Dag and others for those many years of hard work, but I think it’s time to move on. Now I only use it as a last-resort repo for stuff I can’t find anywhere else (disabled by default and low priority).
Nicolas Thierry-Mieg wrote:
Seconded – *much* thanks to Dag for those years.
mark
+100! Dag’s repo has been great, especially before EPEL was born… It made EL usable for many more people.
Absolutely. That’s why I sent Dag a Christmas card (by post) expressing my appreciation. He has performed an invaluable service to many, many thousands of CentOS users (OK, sys admins if you prefer).
5 thoughts on - Package Conflict With Libmodplug In Rpmforge And In Rpmforge And Epel
CentOS@kcburns.com wrote:
No. The problem is the way the packages are built into .rpms. I’ve seen yum give up on stuff in the standard repos, because the manpages from a i386 package conflicted with the manpages from a package, sometimes the
*same* package… but that was the x86_64 version. The rules for the rpm install can specify (or not) whether to allow for this… but both epel and rpmfusion have packages compatible with the base, and seem to do pretty well with each other, while rpmforge doesn’t consider them.
The upshot is that a package will want, for example, a specific library that you *have*… but it was installed in package x.y.6, while the one from repoforge is expecting it to have come from *their* package q.j.6. The result is that it fails to install.
Is that any clearer?
mark
it helps a lot, if you set up all your repos with appropriate priorities right at the beginning. Or you can later on add a repo with a lower priority (so, higher priority= value). But even so, yum-priorities is not a magic bullet and there will be issues occasionally. And some choices will have to be made, by you the user. There’s no getting around that. In those cases priorities will usually tell you that there is a conflict, and you then make your decision and implement it (eg with excludes). Mark’s scenario falls into that category: libfoo v1.1 is installed from your high priority (HP) repo, but you want bar from the lower priority (LP) repo and bar requires libfoo v1.2, which is in the LP repo and mutually incompatible with v1.1. Then if you really want to install bar, you’ll have to exclude libfoo from the HP repo. That may prevent future package installs from HP, if they require the specific v1.1 version of libfoo.
repoforge/rpmforge/Dag has been a fantastic resource for ages, but today it’s pretty much dead in the water despite some good people trying to step in to help keep it afloat. Many thanks to Dag and others for those many years of hard work, but I think it’s time to move on. Now I only use it as a last-resort repo for stuff I can’t find anywhere else (disabled by default and low priority).
Nicolas Thierry-Mieg wrote:
Seconded – *much* thanks to Dag for those years.
mark
+100! Dag’s repo has been great, especially before EPEL was born… It made EL usable for many more people.
Absolutely. That’s why I sent Dag a Christmas card (by post) expressing my appreciation. He has performed an invaluable service to many, many thousands of CentOS users (OK, sys admins if you prefer).