[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Re: I can't maintain Fedora Core 1 Subversion RPMs any more (Re: 1.0.3 release scheduling)

From: Matthew Rich <mrich_at_tigris.org>
Date: 2004-05-24 23:37:28 CEST

another small problem: it seems like the release tarball contains neon/,
while doing a checkout doesn't, hence building the rpm from a WC would
use the installed neon libraries, and building an rpm from the release
tarball always uses the provided neon source code (which breaks the rpm
by installing files in the buildroot which aren't packaged, which, of
course, is not a problem with older versions of RHL).

I assume that when building an rpm, we always want to use the existing
(installed) neon rpm: so it seems that the simplest solution would be to
change the subversion spec file to always specify something like:

--with-neon=%{_prefix}

(rather than depending on the default behavior of the neon macro),
the other solution would be to tweak neon.m4 to not be so strict about
defaulting to building the source code in neon/

btw, posted 1.0.4

Matt

On Fri, 2004-05-21 at 01:07, Matthew Rich wrote:
> > I've been including that patch (merged from the 1.0.0 branch) for the last
> > three releases. Yes, it has to be included (patched/merged) into each
> > build.
> >
> > Fortunately, that should change tomorrow with the release of the 1.0.4 as
> > the patch to fix it (which is in trunk) is now scheduled to be merged in
> > to 1.0.X branch tomorrow before 1.0.4 is released.
> oh :P
>
> > > The fact that your package build scripts require a repository working
> > > copy seems a bit contrary to the whole: pristine-source->port&patch
> > > concept though, which is right up there with: why doesn't tigris.org
> > > support SSL (the mind boggles), but in any case 1.0.3 is built. You can
> > > have them if you want them :)
> >
> > Hmm. Well, sort of. But I really like just typing "make" or "make
> > RELEASE=1" in the working copy to build a complete system. Along the way,
> > it generates a tar-ball, so if anyone else comes along and tries to just
> > build from the tar-ball, that works also. Maybe "pre-prestine" source
> > code? :-)
> no problem there, but it doesn't seem to work with the release tar-ball,
> which complains about this not being a working copy of course :(. I
> always liked doing:
>
> rpmbuild -ta subversion-1.0.3.tar.gz
>
> but that obviously wouldn't work with so many different spec files.
>
> Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 25 05:21:07 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.