[svlug] Rebuilding RPMS problem.

[Michael C. Robinson]

So everything is pretty much really old, except maybe for the minimal
install of CentOS 7.  Fine, just install an rpm build environment,
replace the source in the preferred source rpm, and build a newer
software package.  That is great, unless you want to replace Perl.
CentOS is so far behind on Perl that the version that comes with 
CentOS is not supported by the Perl community.  I suppose in theory
I could install the ancient system Perl, build a new Perl RPM, and
replace the system Perl with the newer package.

Another problem, the zlib that the minimal install of CentOS 7 
depends on is old.  Try to remove it, yum warns that you will 
essentially bork the whole entire system.  In theory one can 
take newer source and rebuild the zlib rpm installing the newer
zlib over the older one, at least in theory.  May still break
everything.

My hosting provider is switching to Ubuntu on his servers and not 
the LTS releases having been with CentOS for years.

Why does CentOS stay so far behind and why backport fixes to earlier
versions of a software package instead of going to the current stable
that the developer community for that software package is maintaining?

Maybe I should be using Arch Linux, but it sounds like I have 
to build everything manually in Arch Linux and is there any 
package management when I am done?  Arch may not be appropriate 
for a production environment.

The problem that is more serious is deciding how far to go in
rebuilding the CentOS 7 RPM packages.  Should gcc be replaced
with a newer version?  If that is done, does any supporting
software such as glibc need to be updated.  Pretty soon if
I'm not drawing a line somewhere reasonable, I'm jettisoning
all of the packages and building everything from source.  At
what point is there no sense in using CentOS 7?  What would be
a better choice?  Fedora server spin?