[CentOS] Perl package problems
Ljubomir Ljubojevic
office at plnet.rs
Thu Dec 15 20:12:30 UTC 2011
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
More information about the CentOS
mailing list