CentOS - Apr 2014 - package conflict with libmodplug in rpmforge and in rpmforge and epel

On 04/16/2014 05:33 PM, m.roth at 5-cent.us wrote:
> And no, do *NOT* use epel and repoforge - they very frequently have
> conflicts, due to prerequisites of packaging.
Does the use of yum priorities take care of this concern?


Thanks,
Ken

centos at kcburns.com wrote:
> On 04/16/2014 05:33 PM, m.roth at 5-cent.us wrote:
>> And no, do *NOT* use epel and repoforge - they very frequently have
>> conflicts, due to prerequisites of packaging.
>
> Does the use of yum priorities take care of this concern?
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

On 04/17/2014 07:50 PM, centos at kcburns.com wrote:
> On 04/16/2014 05:33 PM, m.roth at 5-cent.us wrote:
>> And no, do *NOT* use epel and repoforge - they very frequently have
>> conflicts, due to prerequisites of packaging.
>
> Does the use of yum priorities take care of this concern?
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).