--On Saturday, December 10, 2005 12:45 PM -0600 David Summers
<david@summersoft.fay.ar.us> wrote:
>> Ideally a single spec file exists in the tarball, so that one can just
>> recreate the package from the tarball with "rpmbuild -ta". That requires
>> that one use distro detection within the spec file to handle the
>> differences. That should also make it easier to maintain the spec files
>> and keep the common parts in sync. (RHEL 3 and 4 seem to differ
>> primarily in the versioned python directory name, 2.2 versus 2.3. Put
>> that in a macro at the top and the rest of the file should be almost
>> identical.)
>
> That would be great. Patches greatly welcome, or describe to me how that
> could be done and I'll work on it.
If you look in the existing rhel-4 spec file, you see %if used to control
which subpackages get built. A similar idiom can be used to control
distro-specific stuff.
The distro could be defaulted to something generic at the top of the spec
file and one could pass in an override with --define 'distro fc2' (for
example).
I'll have to check on the RPM developer list to see how to define a set of
macros conditionally based on the value of another macro (eg. the python
version based on the distro). Like "if distro == rhel3 then pythondir =
python2.2".
Also, you might want to look at Red Hat's most-recent SRPM. Minimizing
differences between the SRPM's provided by distros and the upstream build
means less things for an admin to check for compatibility. (Ie. the "why
did he do this different?" check.)
<http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/
subversion-1.2.3-5.src.rpm>
You might find some useful idioms here:
<http://fedoraproject.org/wiki/PackagingGuidelines>
(Does SUSE have an equivalent page?)
>> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 10 20:41:14 2005