On Sun, Nov 3, 2013 at 3:35 PM, Branko Čibej <br...@wandisco.com> wrote: > On 03.11.2013 20:29, Nico Kadel-Garcia wrote: > > I'm going to give you my Red Hat/Fedora classic advice. > > Work From The RPM > > > That's not really helpful. People have legitimate reasons to build from > source, and you definitely won't find an (S)RPM with the latest trunk. It > really is mostly trivial to build from source on Linux. you just have to > make sure you have the headers and libs for all the dependencies installed, > and -- apart from Serf -- all of those should have standard development > packages on most any Linux distro.
If you just want the latest version, it is *very* helpful. The latest version from RawHide, which is the development release for Fedora, is subversion-1.8.3. The SRPM builds fine on Fedora 19, and it provides a good testing base. Building it with "mock" can even separate your build environment from weird locally modified libraries, and gives that much better of a chance of it working in production. I do development versions of software wrapped in RPM's as a matter of course to make sure I have a clean and replicable deployment layout, by building the RPM with "mock". They also give me a "remove and replace this package" option which is very, very difficult with most source tarballs. Taking the SRPM for subversion-1.8,3 and updating it to subversion-1.8.4 provokes XFAIL erors in the build testing, which I don't personally have time to pursue. But it's a better starting place, since the apr and other libraries (which you mention below are better defined. There's also always a risk when you start building and laying out your own copy of system libraries (such as those from httpd) that you will overlap or intermingle components in destabilizing ways. (LD_LIBRARY_PATH discrepancies, or compile time "-I" options that use "/usr/includ" then "/usr/local/include" in one part, then "/usr/local/include" and "/usr/include" in another drive me bugfutz." > The hints about "incompatilbe libc" seem to be implying that at least some > of your dependencies are not compatible (whatever that means) with the > updated system libraries. You'll have to rebuild those dependencies or, > better yet, install them with yum. > > For example, I suspect you build APR from source, since Subversion is trying > to use its copy of libtool. Which is why he should ideally be using the httpd and httpd-devel packages, rather than a locally built httpd package. The interweaving for sub-components in complex software gets awkward and hard to control, especially if installing *another* dependency for other work introduces a dependency on httpd-devel and it winds up lying around parallel the the hand-built httpd. That way lies madness. There can be reasons to need the latest/greatest trunk versions of httpd or subversion, but unless you want to be a core developer, you should really be working from a tag or stable "vendor" release. Or better yet, grab Wandisco's RPM's and take a look: their commercial support for multi-master environments is still the best for high availability Subversion that I've seen. > > -- Brane > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. br...@wandisco.com
