Should I use the CentOS package version in the (official) repositories, or the latest stable versions of the packages?

Generally, I try very hard to use system default packages.

However, this is sometime not possible. To do an educated choice you had to answer these questions:

1. do the distribution's packages provide the features you require? If so, you don't even need to search for other packages; simply use the packages provided by system repositories.
2. do you need official support and/or had you to comply to specific policies? If so, you can't use an unofficial repository. In this case, you are probably using the wrong distribution for your software project.
3. if the answer to the previous questions was "no", you had to search for a more recent software version. Does exist a well-recognized repository with the required package? If so, use it.
4. if no specific, reputable repositories exist, you had to use the upstream software. In this case, try very hard to use packaged software (eg: RPM, DEB, ecc) rather than plain tar.gz (or the likes).

Matthew Ife's and shodanshok's answers cover the issues in general, but I want to address your specific concern by putting the issues in context, as it is exactly these sorts of systems that I manage.

My current build for deploying PHP/MySQL web apps is:

• CentOS 7.x
• nginx 1.8.x provided by nginx
• PHP 7 or PHP 5.6 (depending on the application) provided by remi
• MariaDB 10.0.x provided by MariaDB

First, let's consider why we choose a particular distribution or package set. Either we value stability over the latest features, or we value the latest features over stability. It's not generally possible to have both in the same distribution, as stabilizing software requires time to fix bugs, and adding new features introduces bugs, thus instability.

As a general rule I want the operating system on which the application runs to be as stable as possible, but with a reasonably modern feature set. Thus I'll choose CentOS 7 over CentOS 6, which is rather old at this point, and while it will work, it doesn't have as much time left in its support lifecycle, so I won't use it for a new project.

However, I then ran into the issue that the version of nginx included with CentOS was too old and did not have some required features and bug fixes. Thus I went searching for alternate packages, and found that nginx.org distributes their own. I switched to them almost immediately and have found them perfectly stable over the long haul.

Then there is PHP. I know from history that the version of PHP shipped with CentOS will be the only version it ever gets, and will only get security updates; no new features or bug fixes. Thus, once it is out of support upstream, I am eventually going to be unable to run modern PHP web applications if I use those packages. Thus it's necessary to replace these as well.

From long experience I've learned that it's best to track bugfix releases with PHP, not simply to freeze at one point release and take only security fixes, as the web applications I run will also be updated and will need those bugfixes. So after evaluating many different sets of PHP packages, I settled upon remi's pacakges. Remi happens to be a Red Hat employee and is also responsible for the PHP packages in RHEL/CentOS. So I know his packages will be high quality, and they have been. They are drop-in replacements for the system packages and work perfectly.

Finally we get to MariaDB. You can choose to keep the system packages here and suffer no ill effects. I chose to switch to MariaDB's 10.0 packages (and soon will go to 10.1) to take advantage of TokuDB and some other performance enhancements not available in the 5.5 version shipped with CentOS, and that it will never receive major upgrades for.

Overall you need stability in your base system, but web apps change much more rapidly than, say, line of business software, and your server will need to keep up. Thus I've chosen targeted points where upgrading packages will gain clear benefits with little additional administrative overhead (a.k.a. work).

The short answer is, always use whats provided by the system repositories. Be very careful what repositories you do install too. Some are just plain bad.

You shouldn't ovewrite the systems packages with newer versions, Redhat is designed and orchestrated very carefully and you might end up with strange bugs or problems if you do.

Some things to consider and look out for which can cause issues include.

1. Some repositories are simply badly maintained. They dont update with security fixes for packages.
2. People tend to write bad RPMs, they dont mark config files as config files, which overwrites your config each time you update, which could cause problems. I've seen this problem before.
3. They do not sufficiently declare their dependencies properly. I've seen this before too, where a php package was put on the system but didn't update the pear package which introduced issues.
4. Installing multiple repositories all offering the same package names can lead to unforeseen dependency problems on your system.
5. Some packages overwrite or rewrite system configuration files that other packages depend or expect to exist. This leads to problems with other packages you might not expect.

Never build packages from source and install them over the top of the packages that are there. This breaks your systems package integrity which can lead to strange ABI problems like receiving unresolved symbol or undefined reference messages. It is pretty critical the system maintains a reliable and accurate index as to what software has been deployed on a given system to ensure that it all works with each other properly, this is the reason we use RPMs in the first place.

The viable (and Redhat blessed) way to go about resolving this is to use software collections.

www.softwarecollections.org

It installs is software and its 'new' dependencies in its own root. This can make it slightly harder to apply the package in your environment but does protect your system from weird errors or problems. It also installs the packages in their own namespace, letting you install multiple versions of a package in parallel.

The website gives instructions how to install and activate these packages, it contains most of what people miss on older versions of CentOS and Redhat (EL6 in particular). Some things I've used from this website successfully.

• MySQL 5.6 and MySQL 5.7, MariaDB.
• PHP 5.5 and PHP 5.6
• Apache 2.4

Note that your default position on this matter should be not to adjust from what the Redhat repositories are pushing. Instead, make an assessment as to whether you really do need an updated version of a package, in particular what your specific requirements are, what problems it is supposed to fix and what risks it introduces.

As a general rule, if you find yourself constantly needing updated software and/or requires multiple parallel versions of the same packages to make things work it is usually an indicator you are doing something wrong.