On Sun, Nov 3, 2013 at 3:35 PM, Branko Čibej <brane_at_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. brane_at_wandisco.com
Received on 2013-11-04 14:54:21 CET