Building Subversion 1.85
(2014-01-16)
Problem
I want to run Subversion v1.85, client and server, on CentOS 5 (today's victim server is 5.10).
Solution
You can't do that. Well you can, but it is ugly.
You have several problems:
- Subversion wants a newer version of sqlite than is shipped with CentOS-5.
- Subversion depends on serf for http access.
- Serf depends on newer versions of apr and apr-util than ship with CentOS-5.
- apr and apr-util are intimately related to the apache you intend to use to run the server component.
- oh and just to ensure you shave the requisite number of yaks, Serf requires a build system I've never heard of before.
So I had a bunch of choices, most of which boiled down to
- throw CentOS-5 away (not viable for other reasons)
- build a whole Apache for Subversion to use (something I would rather avoid if at all possible)
- build two instances of Subversion: one for the installed CentOS-5 Apache, and one with more modern libraries
The last option is a hack, but I tried it and it worked for me.
Things I downloaded:
- apr 1.5.0
- apr-util 1.5.3
- scons-local-2.3.0
- serf-1.3.3
- sqlite-autoconf-3080200
- subversion-1.8.5
Everything else was satisfied with yum. (I have EPEL loaded but I think all other dependencies came from the Base or Update repositories.)
I'm installing things out-of-tree because I want all this junk usable from arbitrary systems on the network. In this case one component of all the prefix values is C5-32, for CentOS-5 32-bit, because I also have A) CentOS-6 and B) CentOS-5 64-bit systems around. This process was repeated for C5-64 (the client-side anyways) and it still worked.
So to repeat: if you do this you'll end up with two full builds of Subversion, one for Apache and one for the client. You can probably get rid of most of the stuff in the Apache install tree but frankly disk space is cheap these days.
Your overview:
- build sqlite
- build subversion the first time
- build apr
- build apr-util
- build serf-1.3.3
- build subersion the second time in a different location
- mess with the httpd conf file
- restart httpd
Server Pieces
Build sqlite
$ ./configure --prefix=/projects/common/C5-32/sqlite/3080200
$ make ; make install
Build Subversion The First Time
This is the build that the running apache from CentOS 5 is going to use.
# ./configure --prefix=/projects/common/C5-32/subversion/1.8.5-server --with-sqlite=/projects/common/C5-32/sqlite/3080200
# make ; make install
httpd conf changes:
I have this file as /etc/httpd/conf.d/subversion.conf
LoadModule dav_svn_module /projects/common/C5-32/subversion/1.8.5-server/libexec/mod_dav_svn.so
LoadModule authz_svn_module /projects/common/C5-32/subversion/1.8.5-server/libexec/mod_authz_svn.so
<Location /svn_dgm>
DAV svn
SVNPath /var/www/svn/svn_dgm
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/svn-auth
Require valid-user
</Location>
Create /etc/svn-auth as usual; create yourself the repository at /var/www/svn/svn_dgm; and restart httpd.
Client Build
Build sqlite
As above, if you have not done so already. Otherwise, proceed.
Build apr
$ ./configure --prefix=/projects/common/C5-32/apr/1.5.0
$ make ; make install
Build apr-util
I installed this into the same tree as the apr. In hindsight this might not have been the brightest move I could have made. However it A) hasn't bitten me yet and B) how I did this, so there you are.
$ ./configure --prefix=/projects/common/C5-32/apr/1.5.0 --with-apr=/projects/common/C5-32/apr/1.5.0
$ make ; make install
Install scons
Yes, lets shave them yaks. Yet another build tool because autoconf just working is old and busted for some reason. This sequence is how I did it; if you want/need for scons for something else you might want to be more permanent about it.
$ mkdir ~/local
$ cd ~/local
$ tar xfz ~/Downloads/scons-local-2.3.0.tar.gz
Build and install serf
This is the library that handles the http access scheme for svn. It requires an updated apr/apr-util. If you try to build against the CentOS-5 versions, you get an error which some googling will eventually lead you to some snide comments about how "nobody should have any business running such old software versions".
First thing to do is to make scons.py reachable in the local directory, then build and install serf:
$ ln -s ~/build/local/scons.py scons.py
$ ./scons.py PREFIX=/projects/common/C5-32/serf/1.3.3 APR=/projects/common/C5-32/apr/1.5.0 APU=/projects/common/C5-32/apr
/1.5.0 $ ./scons.py install
Build and install Subversion a second time
This build instance is the one that users will actually use. Note the different prefix value for installation.
$ ./configure --prefix=/projects/common/C5-32/subversion/1.8.5 --with-apr=/projects/common/C5-32/apr/1.5.0 --with-apr-util=/projects/common/C5-32/apr/1.5.0 --with-sqlite=/projects/common/C5-32/sqlite/3080200 --with-serf=/projects/common/C5-32/serf/1.3.3 --with-sasl
$ make ; make install
Client environment
In order to access the new svn client, each user must do this to their environment:
$ export LD_LIBRARY_PATH=/projects/common/C5-32/serf/1.3.3/lib/:$LD_LIBRARY_PATH $ export PATH=/projects/common/C5-32/subversion/1.8.5/bin:$PATH
Now subversion is available:
$ svn --version
-bash: subversion: command not found
[dmackintosh@cvshost subversion-1.8.5]$ svn --version
svn, version 1.8.5 (r1542147)
compiled Jan 16 2014, 12:57:21 on i686-pc-linux-gnu
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see [http://subversion.apache.org/](https://web.archive.org/web/20231208034141/http://subversion.apache.org/)
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.3
- handles 'http' scheme
- handles 'https' scheme