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

RPM packaging components in trunk out of date and dangerous

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sat, 2 Jul 2011 10:39:01 -0400

The RPM packaging comonents in trunk/packages/rpm are out of date,
unusable, and likely to destroy a developer's build environment. They
should either be completely disabled or seriously updated. There are a
couple of different issues, which I'll describe in order:

* All the Makefiles replace the users's $HOME/.rpmmacros without
warning. This is devastating to a user who has GPG signature
configurations there, or who does their RPM compilation in a non
$HOME/rpm location, or who follows RHEL standard uppercase naming of
the SRPMS, SPEC, RPMS, and BUILD subdirectories, because the published
".rpmmacros" file follows a non-standard lowercase layout.

Instead of relying on a hard-coded .rpmmacros, the Makefiles should
use "rpm --showrc" command to derive the topdir, sourcedir, etc.

* The .rpmmacros file ignores the "BUILDROOT" setting common to modern
RPM building environments.

* The .rpmmacros file should be renamed. It should be "rpmmacros.in",
so it's presence is apparent to the developer, and to show that it is
*not* in fact, the actual file installed.

* The .spec files should be renamed to "subversion.spec.in". These
are not the .spec files and should not appear as such in Subversion
source code tarballs, they are source files for building .spec files.

* Modern subversion cannot be compiled on rhel-3, and that packaging
should be discarded.

* Modern subversion cannot be compiled on rhel-4, and that packaging
should be discarded.

* Modern subversion can be built on rhel-5, rhel-6, fedora, etc. Those
packages can be published as *one* set using the RPMforge packages.
(I'm an old contributor to those.) There are some issues with this,
particularly its inclusion of the "swig-3.4.0.tar.gz" tarball for RHEL
4 compilation which doesn't even work anymore, but it's a better
starting base for this packaging.

I'm happy to submit these as distinct issues for the issue tracker,
but in the short therm, pulling out the unusable rhel-3 and rhel-4
packaging would be a good start.
Received on 2011-07-02 16:39:33 CEST

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.