[CentOS] Repositories in CentOS 5.8

[Lamar Owen]

On Tuesday, May 22, 2012 12:17:07 PM Kaushal Shriyan wrote:
> I am running Cent OS 5.8 in production. Can someone please explain me about
> various repositories available in CentOS 5.8 and which third party repos (
> http://wiki.centos.org/AdditionalResources/Repositories) i should use it in
> Production environment.

You've already gotten some excellent advice about this, but I'd like to add a few things, starting with a list of just a few factoids I've observed about repos and repo mixing:

1.) EPEL doesn't make it a priority (or even a goal) to work well with any other third-party repository;

2.) The mixability of other repos varies, with both repoforge/RPMforge and ELrepo taking pains to not overwrite base repo packages unless you enable their 'extras' sub-repos (others may as well, I'm speaking from my own experience, and the repos I use the most are EPEL, repoforge, and ELrepo, and so I'm not even going to comment about the mixability of others, like remi, IUS, ATrpms, or others since I have either insufficient or old information about them);

3.) At least one useful repository that I use on certain production machines, the CERT Forensics repo, relies on both EPEL and RPMforge/repoforge, so look carefully at the mixing issues of each of your selected repos' upstream repo dependencies;

4.) Random mixing of packages (like random downloads from pkgs.org) is certain to cause problems;

5.) The fewer the number of repos you use the more stable your package set will be.  That is especially true if you mix 'specialty' repos like OpenNMS and PacketFence (or even slightly off the wall ones like LinuxTech (which has a usable handbrake for CentOS 6, for instance)), or upstream repos like the one from the PostgreSQL RPM building project to get the latest PostgreSQL on you system;

6.) There is no such thing in repositories as 'one size fits all.'  What will fit your needs depends a great deal on what 'production' is defined to be in your specific instance.  

(For a server in 'production' that is serving typical network service loads (file, print, web, e-mail, databases, etc) you're going to need some specific things (where 'things' is defined as the set of packages and interdependencies between packages).  A 'production' research/development desktop (we have a few here) will need different things; a 'production' embedded machine controller (we have a couple of those, too) will need yet another different set of things.);

7.) You really need to look at the packages that you need for your application and then individually investigate which repo or repos has the packages that you need, built the way you need them.  And look at the longevity of the repo; both RPMforge/repoforge and EPEL, for instance, have been around a while and are pretty well maintained;

8.) The recommendations on the CentOS Wiki repositories page are very good starting points, but what you specifically need in production is something you'll need to determine for yourself after doing some testing with different repos.  And I'd keep some testing machines or VM's available to test various repos over time to see how they work or don't work with each other, and you might even want to build your own repository, depending upon your specific critieria;

9.) Don't mix from-source (./configure;make;make install) installed packages and packages from repositories unless:
	a.) You know exactly what you're doing;
	b.) The from-source package builds all its own dependencies (like Plone does);
	c.) The from-source package's author won't support it otherwise.

10.) Learn to use yum and its tools effectively to keep mixing issues at bay (priorities, plugins, and the command line parameters to enable and disable individual repositories as needed are the ones to start with);

Now, a non-factoid observation: if you think about it, it's quite an amazing thing that so many people are so willing to keep repositories of packages up to date at no cost to the end-user, given the very definite benefit and value of those updates (which is why I can't really complain if a repo is a little out of date, or if two repos that aren't costing me any opex won't mix just the way I want them to) and the very real cost to the maintainer, in terms of time, stress, frustration, and money.  

Having kept packages up to date for public consumption before, I understand all too well the trials of a packager and the entitlement syndrome some users seem to have.  

And thus my last recommendation: 

11.) be prepared to do some work on your own to make different repositories work together for you, and be patient with the maintainers of those repositories when they don't work together the way you might like.  They don't have to listen to you, but most will listen if you approach them the right way, respectfully acknowledging their valuable contribution to your bottom line.

YMMV, FWIW, IMHO, HTH, etc.