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

.spec files for RHEL 5 simply do not work for building RPM's

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sun, 24 Jan 2010 11:47:46 -0500

It seems quite obvious that the existing .spec files from
packages/rpms/rhel-*/ directories have not been used in years. They
represent a considerable amount of work by David Sommers and other
contributors (perhaps including a few patches from me?), but
definitely need update. The contemporary version at RPMforge works
quite well, along with a few minor patch files. I'd like to urge
switching to the RPMforge format, ASAP.

Roadblock problems include:

* Lack of or mishandling of necessary components for compilation under
RHEL 5, such as:
  * swig-1.3.39 tarball
  * neon-0.28.4 tarball
  * Python-2.4.6 tarball
  * sqlite-amalgamation-3.6.13 tarball
* Lack of useful patches from RPMforge, such as:
  * subversion-0.20.1-deplibs.patch
  * subversion-1.1.3-java.patch
  * subversion-1.6.0-pie.patch
  * subversion-1.6.0-rpath.patch (The one present works, it's just
pretty seriously out of date).

Other, less critical issues include:

* The "RELEASE" management in the packages/rpms/rhel-5/Makefile
probably should *never* touch the user's .rpmmacros, if they have one.
As it exists, it overwrites the $HOME/.rpmmacros the first time the
.rpmmacros is generated. Frankly, that .rpmmacros file should be
.rpmmacros.in, and the .in file massaged to generate a
$HOME/.rpmmacros. But the dependencies are.... awkward. Since
.rpmmacros may be modified by other tools, such as GPG key handling
tools, it should probably generate a backup file (if one does not
already exist) and only then create a new .rpmmacros.

* The "subversion.spec" file shouldn't be. It should be a
"subversion.spec.in" file, and the new subversion.spec file generated

* I think that the "RELEASE" can safely be set to 0.test as a default.
This allows local building of .spec files and RPM's without too much
additional handling.
Received on 2010-01-24 18:38:45 CET

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

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