[suggest] Subversion 1.4 package broken
dag at wieers.com
Thu Jan 18 21:17:20 CET 2007
On Fri, 19 Jan 2007, Tim Whittington wrote:
> >>> On 19/01/2007 at 6:04 a.m., in message <Pine.LNX.4.64.0701181749200.23504 at horsea.3ti.be>, Dag Wieers <dag at wieers.com> wrote:
> On Wed, 17 Jan 2007, Tim Whittington wrote:
> > > >>> On 16/01/2007 at 8:27 p.m., in message <45AC7E5B.8030607 at karan.org>, Karanbir Singh <mail-lists at karan.org> wrote:
> > > Tim Whittington wrote:
> > > > The Subversion 1.4 package appears to be broken.
> > > > The build logs indicate that this is a missing dependency on apr,
> > > > which was introduced starting with Subversion 1.4 (the <= 1.3 builds
> > > > appear fine).
> > > >
> > > > There's an apr directory on DAGs old site, but it's not in the
> > > > package listing.
> > > >
> > > > There do appear to be fairly up-to-date RPM builds of apr (and
> > > > apr-util, apr-devel, apr-util-devel) on the Apache download site
> > > > (http://apache.hoxt.com/apr/binaries/rpm/).
> > > >
> > > > Would it be possible to get this dependency sorted?
> > >
> > > not onto the EL4 repo's please! unless svn can be built with the apr
> > > stuff statically included within the svn packages.
> > > Upgrading the distro apr-* is not going to be very nice for all the
> > > other things that also depend on it. ( and the pcre issue too )
> > Are there packages with exact dependencies that upgrading apr would break?
> > I managed to upgrade all the apr packages from 0.9.4 to 0.9.12 as all the deps I had were >= 0.9.4.
> > Post upgrade , I don't have a problem with httpd, httpd-devel etc. etc.
> The issue really is whether people would want that, even if it doesn't
> seem to break anything. This thing comes up from time to time and I'm
> between a rock and a hard place here. Either I override base (upstream)
> packages and I get half of the userbase against me, or I don't and I got
> the other half screaming for something.
> apr to me seems something that other stuff rely on. I cannot
> jeopardize other people's systems upgrading it. Even though people are
> responsible for their own systems and I do not guarantee anything...
> Fact is that doing things like that could simplify my work immensly (like
> upgrading rpm, make and other basic tools) but then there wouldn't be any
> difference between distributions anymore if I go and start upgrading
> gnome, glibc, the kernel and what not to make this or that work.
> We'd end up being another Fedora project :)
> That's why we could do it statically (like is done with subversion 1.3) or
> we simply say that if you need subversion 1.4, you need to upgrade to EL5
> (whenever it is ready).
> There are many reasons why someone would want to have subversion 1.4, I
> can imagine. But are these really that important ? subversion 1.3 is
> working fine over here.
> OK, good reasons.
> We've got some software with SVN 1.4 dependencies (however sane that
> may be), which is why it's important to us.
> How hard would it be to get SVN building with a statically linked apr
> - is this something I could help with? (I know my way round a Linux
> build, but RPM builds are somewhat new to me).
Of course you could help :) Look at the subversion 1.3 buildlogs for eg.
el4 and see what they do to build subversion. Then add a more recent apr
to the SPEC file and try to build it similarly to how subversion 1.3
I assume there are specific configure flags to build statically for only
apr (as that was done for subversion 1.3) but if they removed it, you may
have to tweak either configure or the makefiles afterwards. We do not want
to end up with a complete statically build subversion.
Also, care must be taken to look what everything builds against. We don't
want to risk being vulnerable to a known security problem that gets
unpatched because we build statically.
The easiest is to check the difference afterwards with your dynamically
build binary and with the 1.3 binaries.
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the users