On 6/15/2011 6:54 AM, Nicolas Thierry-Mieg wrote: > Timothy Murphy wrote: >> >> Am I alone in regarding epel as more or less a part of CentOS? >> Does it have a rival in this role? > > you may not be alone, but you're still wrong: epel is not part of centos > at all. > It's just another third party repo. > There are others including some reputable and widely used: > http://wiki.centos.org/AdditionalResources/Repositories It is the distribution and repository policies that make the third party repos both necessary and problematic. Start with the upstream distro policy of not including things that aren't source-redistributable or have potential patent issues in the US, so many people are forced elsewhere for usable video drivers and media players. EPEL also follows these policies (being maintained by the same company...) and also has a policy of not overwriting upstream packages (where upstream is RH, not including centos extras/plus...). So EPEL is generally safe as the only 3rd party addition, but it also won't have what you need. Then there is the usually-followed policy of not updating packages to new versions within the life of the distro. So, for example, subversion stayed at the ancient 1.4.x release shipped with 5.0 well beyond the time the subversion team said to stop using it and update. Rpmforge is the place to go for that sort of thing. Until recently they had everything in one repo and many of the packages were newer than the stock set, making it both useful and dangerous in terms of creating dependency conflicts. It has recently been split into 3 repos so you have more control over replacing stock packages or not (do a 'yum update rpmforge-release' if you have it enabled, then look at the repo entries). But, there is no coordination among the 3rd parties or the main distro. So, if you had updated subversion and viewvc from rpmforge to get code that the developers would still recommend using, and you also had epel enabled, at some point your viewvc package would flip to an update from epel with an incompatible configuration. Then when upstream saw the error of its ways and finally went to a 1.6.x subversion in the base 5.6 release, your update might flip there, with a bunch of unresolved dependencies left over from the running rpmforge package. Fun stuff. For something even weirder, look at what you would have had to do to keep a working and up to date java on a RH-style machine across the life of the 5.x distribution. -- Les Mikesell lesmikesell at gmail.com