Hi Christoph,
Comments are inline:
Christoph Maser wrote:
Am Dienstag, den 12.05.2009, 09:23 +0200 schrieb Greg Bailey:
Regarding Subversion 1.6.2 on CentOS 4:
Extending the idea of embedding required dependencies in the subversion
source tree, I'm able to build Subversion 1.6.2 on CentOS 4 that doesn't
require any external development RPMs to be installed first, and doesn't
require the user to upgrade apr, neon, sqlite, etc. The only ugly part
is that I included python 2.4.6 in the source RPM, and it is built
before the rest of subversion (but only affects the source RPM).
I've made test RPMs available at:
http://lxpro.com/subversion/el4/RPMS/
I'm attaching the patch to the subversion .spec file below.
thanks,
Greg
Well of course i have played with that too at least with the neon part
to build 1.5 on EL4. It builds ok but it does not run!
Could you elaborate? I tested both mod_dav_svn and subversion 1.6.2
(CentOS 4 build) against both the local and remote subversion
repositories, using both http and https and didn't observe any issues.
At least not the way your spec file does it. One could forc a static
build but i think this is out of question.
I think if you include neon in the subversion source directory, it is
compiled static by default; at least, that's what the output of
./configure seemed to indicate. And, in case the older neon 0.24.7 RPM
is installed (say, because the user has "cadaver" or something else
installed which requires it), then the subversion binaries use the
built-in, correct version.
Why is a static build out of the question? Isn't that what we did with
sqlite?
Another point about the spec you attached, why do you throw away the
neon wich is in the subversion tarball to install another one in the
source treee?
I'm not throwing away neon as it's no longer included in the subversion
tarball. If you're referring to the subversion-deps tarball, I opted to
use neon-0.28.4 directly as the subversion-deps tarball includes other
stuff I don't need nor want like apr, apr-utils, serf, zlib, etc.
Apart from all the technical stuff: Why would we want to do that anyway?
What is so important about it? Why does everybody want to have latest
and greatest subversion? As I said before our subversion versions are
way newer then anything else you get (disregarding repos wich upgrade
base). The standard version on EL4 is 1.1.4!
Users I support want subversion >= 1.5 to do better merge tracking. For
various reasons, I'm not prepared to upgrade the server (yet) to CentOS
5, and there's no way I'd put Fedora on a production server. As the
only difference in dependencies between subversion 1.5 and 1.6 is sqlite
(which has already been dealt with), it seemed reasonable to just build
a 1.6 version. I recognize some people are probably OK with subversion
1.1 from Red Hat, most of the others are probably OK with 1.4.6 as is
currently provided by rpmforge, but there may be others (like me) who
need/want 1.5 or greater.
If this whole subversion thing is really important one should consider
to file a bug upstream. But i really doubt redhat will upgrade python,
neon and sqlite on El4 for this.
I agree; it's a rare app indeed (firefox being a notable exception) that
gets updated in a minor release of RHEL.
Chri
Thanks,
Greg
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
