In commit b560b85 of PR git-lfs#1298 and in
commit git-lfs/build-dockers@64a3a9f of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5, so we can
remove the logic in our rpm/build_rpms.bsh which installed a RedHat
EPEL package only on this platform.

Since the original introduction of the rpm/build_rpms.bsh script in
commit 4a71627 of PR git-lfs#332 it has
checked for the absence of the "go" binary and, if it is not found,
installs the golang package, except on CentOS 5 where fetches and
patches a golang.spec file and then builds a local RPM using that
in order to install Go.

However, in commit b560b85 of PR git-lfs#1298 and
in commit git-lfs/build-dockers@64a3a9f of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5.

And in commit 88430de of PR git-lfs#654 we
updated our CentOS Dockerfiles (before they were moved to the
git-lfs/build-dockers repository) to download and install Go from the
googleapis.com service, and we still continue to do this but as of
commit git-lfs/build-dockers@c638503
in PR git-lfs/build-dockers#35 we now use the golang.org service.

This direct download obviates the logic in our rpm/build_rpms.bsh
script to install the golang package, and the special handling for
CentOS 5 is also obsolete, so we remove this logic from our script.

Since the original introduction of the rpm/build_rpms.bsh script in
commit 4a71627 of PR git-lfs#332 it has
checked for the absence of the "go" binary and, if it is not found,
installs the golang package, except on CentOS 5 where fetches and
patches a golang.spec file and then builds a local RPM using that
in order to install Go.

However, in commit b560b85 of PR git-lfs#1298 and
in commit git-lfs/build-dockers@64a3a9f of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5.

And in commit 88430de of PR git-lfs#654 we
updated our CentOS Dockerfiles (before they were moved to the
git-lfs/build-dockers repository) to download and install Go from the
googleapis.com service, and we still continue to do this but as of
commit git-lfs/build-dockers@c638503
in PR git-lfs/build-dockers#35 we now use the golang.org service.

This direct download obviates the logic in our rpm/build_rpms.bsh
script to install the golang package, and the special handling for
CentOS 5 is also obsolete, so we remove this logic from our script.

In commit b560b85 of PR git-lfs#1298 and in
commit git-lfs/build-dockers@64a3a9f of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5, so we can
remove the logic in our rpm/build_rpms.bsh which installed a RedHat
EPEL package only on this platform.

Since the original introduction of the rpm/build_rpms.bsh script in
commit 4a71627 of PR git-lfs#332 it has
checked for the absence of the "go" binary and, if it is not found,
installs the golang package, except on CentOS 5 where fetches and
patches a golang.spec file and then builds a local RPM using that
in order to install Go.

However, in commit b560b85 of PR git-lfs#1298 and
in commit git-lfs/build-dockers@64a3a9f of
PR git-lfs/build-dockers#3 we dropped support for CentOS 5.

And in commit 88430de of PR git-lfs#654 we
updated our CentOS Dockerfiles (before they were moved to the
git-lfs/build-dockers repository) to download and install Go from the
googleapis.com service, and we still continue to do this but as of
commit git-lfs/build-dockers@c638503
in PR git-lfs/build-dockers#35 we now use the golang.org service.

This direct download obviates the logic in our rpm/build_rpms.bsh
script to install the golang package, and the special handling for
CentOS 5 is also obsolete, so we remove this logic from our script.

We no longer support either CentOS 5 or 6, per commit
b560b85 of PR git-lfs#1298 and commit
git-lfs/build-dockers@64a3a9f
of PR git-lfs/build-dockers#3, and commit
git-lfs/build-dockers@898d9b0
of PR git-lfs/build-dockers#33.

We also now build the Asciidoctor Ruby gem in order to generate
our man pages, rather than using ronn and several other gems,
per commit db9a821 of PR git-lfs#5054.

We therefore update the documentation for our RPM package build
utilities and for our Docker container image build utilities to
reflect these changes.

We no longer support either CentOS 5 or 6, per commit
b560b85 of PR git-lfs#1298 and commit
git-lfs/build-dockers@64a3a9f
of PR git-lfs/build-dockers#3, and commit
git-lfs/build-dockers@898d9b0
of PR git-lfs/build-dockers#33.

We also now build the Asciidoctor Ruby gem in order to generate
our man pages, rather than using ronn and several other gems,
per commit db9a821 of PR git-lfs#5054.

We therefore update the documentation for our RPM package build
utilities and for our Docker container image build utilities to
reflect these changes.

In commit 6006acc in PR git-lfs#976 we
introduced a conditional build clause to the SPEC file use we to
build RPM Linux packages, in an attempt to avoid compiling with
cgo enabled on Red Hat Enterprise Linux (RHEL) 5 and CentOS 5
platforms.  This change was made after the use of the "C" pseudo-
module was introduced into the Git LFS client code in commit
ea16fd5 of PR git-lfs#952, as part of
our initial support for copy-on-write file creation.

In practice, though, this conditional build clause was ineffective,
according to the notes in PR git-lfs#976.  Instead, one of the Dockerfiles
used to build RPM packages for the RHEL/CentOS 5 platform was updated
in commit git-lfs/build-dockers@39cec36
of PR git-lfs/build-dockers#1 to set the CGO_ENABLED environment
variable with a value of "0".

The conditional build clause in our SPEC file was never removed
afterwards, however.  Later, the Dockerfile in which the CGO_ENABLED
environment variable was set was removed in commit
git-lfs/build-dockers@d4c2fe6,
and the primary Dockerfile used for building packages for the
RHEL/CentOS 5 platform was then dropped in commit
git-lfs/build-dockers@64a3a9f
of PR #3.  This followed the removal of the references to the
RHEL/CentOS 5 platform from the scripts in our "dockers" directory in
commit b560b85 of PR git-lfs#1298.

As there is no value to retaining the conditional build clause
for the RHEL/CentOS 5 platform in the SPEC file for our RPM packages,
we simply remove it now.