Re: Building RPM from rc4

On Sat, 10 Dec 2005, Kenneth Porter wrote:

>>> One of the draws of 1.3.0 is that one no longer needs to depend on the
>>> build host's swig version, but I see build dependencies in the spec
>>> files for swig and a number of other packages that are now included in
>>> the tarball. I'd suggest removing those dependencies unless one really
>>> wants to use the build host's version.
>>>
>>
>> I'm not sure I'm following you there. There is a BuildPreReq for swig as
>> the package builder now has to have swig > 1.3.25, but that is not a
>> dependency in the generated RPM files.
>>
>> The way I'm building it does not use the released tarball but generates
>> the RPMs directly from the Subversion checkout (which is even better
>> IMHO), so I don't have the neon, apr, apr-util, etc., directories in my
>> build, they are required to already be installed on the build and target
>> system.
>
> Building from a checkout implies that you're building from a repo version,
> not from a "release". That should be reflected somehow in the RPM version,
> for instance encoding the repo version in the release number. But an RPM
> representing a release version should always be built from "pristine source",
> ie. the official release tarball.
>
> The generated spec files for building from the repo, if different, could be
> named subversion.spec.in in the tarball and assembled by configure, so that
> only a single unambiguous spec file suitable for building from the release
> tarball is included in the tarball. (This allows the end user to use the
> "rpmbuild -ta" idiom.) The latter is built during the "make tar" step.
>

I'm all for making things better. I'm not sure why "Building from a
checkout implies that you're building from a repo version, not from a
'release'". For instance, when I build my final RPMs for a release I
checkout from the tag and build. I know it is *different* than most
people are used to, I just haven't seen that it makes a big difference.
Maybe it does. Most of the time when a packager builds an RPM they are
not building directly out of the source control, they have a "release"
tarball that they build from. In that situation I would agree with
you. However, since I'm building directly out of the soure control, it
sure makes it nice to do it this way from my point of view.

To address your point; I normally build a NAME-VERSION-RELEASE and call
it RELEASE 1. Then, after I distribute it, if there are any problems and
I have to make another one, I add language to the changelog and release a
new and and call it RELEASE 2, etc. Kind of the same as a normal pristine
sources and packager release procedure but a bit different.

I suppose I could run the "dist.sh" procedure during the RPM generation
sequence but I don't like that becuase it requires downloading the latest
neon, apr, apr-util, etc, which I'm just throwing away during my RPM build
anyway because I am relying on the already installed versions instead of
the "latest" at the time of the build. On platforms with existing neon,
apr, apr-util, bdb, etc., it is important to use the platform installed
versions, otherwise we get into a big mess with trying to have shoe-horn
in new depedencies with software which already has existing dependencies.
I hope I said that all correctly. Anyway, I've tried running different
BDB and APR/APR-UTIL with stuff before. It can be done but is a big
headache so far. Maybe I'm doing something wrong.

Thanks for your feedback.

-- 
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 =  0B44 B118 85CC F4EC 7021  1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org