Vreme: 12/15/2011 08:27 PM, Les Mikesell piše: > On Thu, Dec 15, 2011 at 10:24 AM, Ljubomir Ljubojevic<office at plnet.rs> wrote: >> >> You can keep all desired repositories enabled as long as you have >> yum-plugin-priorities installed and keep third-party repositories with >> lesser priority (larger number). Like base=1, epel=2, repoforge=3, >> rpmfusion-* =3, etc. > > Does this always do what you want when things appear in different > repos? Like something you have installed from extras being added > later to EPEL, etc.? > Plugin "Priorities" hides packages with the same name, leaving only package from the repo with top most priority (lower number). This prevents visibility and installability of packages in repo's with lower priority (higher number). You can still see them if you add "--showduplicates --disableplugin=priorities". EPEL is base-repo friendly, so there should be no problems with EPEL. Trick comes with RepoForge (ex-RPMForge), aTrpms, and other third party repo's. Policy of the RepoForge for example is that they will not recompile their own packages if package they depend on is bumped in EPEL and overrides RepoForge's package with same name. I do understand them, they have limited time and infrastructure to always keep up with EPEL. But only real problems are with Audio/Video packages: players, codecs (decoders, encoders), and supporting libraries. In order to be sure that those packages will work without interruptions, players are compiled with hard-coded dependencies on particular version of libraries, codec packages, etc. We can narrow it down even further to decoders/encoders with licensing issues like MP3. Upstream, CentOS consequently, and EPEL compile for example gstreamer package without license infringing codecs, but all others do. What people do is to install gstreamer from third party repo with gstreamer-bad (or was it -ugly) additional packages. So when upstream or EPEL publishes another version of gstreamer, hard-coded gstreamer-bad dependancy conflicts with new package. So third-party repo would have to rebuild their entire audio/video "package group" to avoid conflicts. Solution would be that there is communication between EPEL(/upstream) maintainer and third party repos. So there will always be complications, but they are limited to audio/video packages (mostly). -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant