On Mon, 24 May 2004, Matthew Rich wrote:
> 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).
Right, I don't build a release tarball, I just take the existing working
copy and tar it up. Is there some problem with doing that that I'm not
aware of? I've never run into any problems doing that. My next question
is: Why would you build from both the release tarball AND the RPM? I'm
missing something.
> 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
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 05:01:08 2004