I mentioned this in passing recently; today I feel like elaborating on why replacing a distribution package with your own locally built version of something is a big pain in the rear and thus why sysadmins almost never do it.

(I'm going to assume here that you're familiar with building from source in general.)

First, you have two options for how to do this; you can build from source and just do a 'make install', or you can actually (re)build a new package and install it. Doing a raw build from source is horrible for all of the reasons that we have modern package management, plus you're going behind the back of your package management system and this generally doesn't end well.

Rebuilding a package is superficially more attractive, but it causes a number of issues. First, you need to know how to build and rebuild packages for the particular OS that you need the new version of the program on, and to have a build environment suitable for doing this. But let's assume that you can do all of this because you've already invested the time to become a competent package builder for this distribution.

Once you have a package, what you're doing is adding unofficial local packages to the distribution. When you do this, making everything work nicely together becomes your responsibility, and when you override a distribution package instead of adding a new one you also get the headaches of dealing with the distribution's own updates to the package. The distribution may update their version of the package in ways that clash with your version or simply cause your version to be removed, and they may change how the package works in ways that require you to immediately update your own version in order to keep working with the rest of the system.

(In short, you're essentially maintaining a fork of their package and you get to do all of the tracking and updating that that implies.)

In either case you now have to keep track of the upstream version yourself, in order to pick up security issues and (important) bugfixes. If you do not want to lock yourself to using the latest and greatest version, this may include backporting those changes to the older version that you're using. You will probably also want to keep track of the changes that your distribution thinks are important enough to include in their packaged version of the program.

All of this requires more than just work and time; it requires attention (to upstream changes, to distribution changes, to security alerts, etc). Attention is an especially scarce resource for sysadmins, much scarcer than time.

(The one time it starts being worth doing this is when a distribution has hit end of life. In that case, there will be no distribution package changes and the distribution has stopped tracking the upstream for security updates and so on anyways, so either you worry about it or no one will.)