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
dynamically.
* 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