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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
