On Tue, 2005-08-02 at 11:47 -0400, James B. Byrne wrote:
> I am attempting to build from a src.rpm (knowing very little about
> rpm at all) and the spec file notes that the architecture should be
> set on the command line:
>
> > # platform defines - set one below or define the build_xxx on the
> command line
>
> Now. My question is this, how does one do this using rpmbuild?
> The syntax rpmbuild --target centos4 package.src.rpm seemingly has
> no effect.
Should be something like:
$ rpmbuild --rebuild --target=i386-centos4-linux package_name.src.rpm
^^^^
Could possibly be i586, i686, x86_64, ...
or alternately (you'll end up here anyway if the build fails):
$ rpm -ivh package.src.rpm
$ cd rpmbuild/package_name # assuming setup as follows below
$ rpmbuild -ba --target=i386-centos4-linux package_name.spec
Edit spec and/or debug and repeat rpmbuild as necessary until a state of
joy is achieved. :-)
Another bit of unsolicited advice - setting up an end-user build
environment is a prudent approach. Some badly-behaved spec files have
been known to clobber system files when building as root. I build as a
user and put the resulting RPMS in a local repo so they can be installed
with yum. Here's my well-tested setup (as stolen from Mike Harris)...
[prs at wx1 ~]$ cat .rpmmacros
# Custom RPM macros configuration file for building RPM packages
# as a non-root user.
#
# Author: Mike A. Harris <mharris at redhat.com>
#
# This is a copy of my own personal RPM configuration which I use
# on my workstation for building and testing packages for Red Hat Linux.
# There are many different possibilities on how to configure RPM, so
# feel free to tweak however you desire. Make sure to create any
# directories that are referenced prior to using. RPM will automatically
# create some of them if missing, but not all of them. Which ones it
# auto-creates is only known by the extraterrestrial aliens that have
# created RPM.
#
# For ANY help with anything related to RPM development, packaging,
# or customization, please join the Red Hat RPM mailing list by sending
# an email message to: rpm-list-request at redhat.com with the word
# "subscribe" in the Subject: line.
#
# Any suggestions/comments/ for improvements to this setup appreciated.
# %_topdir defines the top directory to be used for RPM building purposes
# By defaultROOT of the buildsystem
%_topdir %(echo $HOME)/rpmbuild
# %_sourcedir is where the source code tarballs, patches, etc. will be
# placed after you do an "rpm -ivh somepackage.1.0-1.src.rpm"
%_sourcedir %{_topdir}/%{name}-%{version}
# %_specdir is where the specfile gets placed when installing a src.rpm. I
# prefer the specfile to be in the same directory as the source tarballs, etc.
%_specdir %{_sourcedir}
# %_tmppath is where temporary scripts are placed during the RPM build
# process as well as the %_buildroot where %install normally dumps files
# prior to packaging up the final binary RPM's.
%_tmppath %{_topdir}/tmp
# %_builddir is where source code tarballs are decompressed, and patches then
# applied when building an RPM package
%_builddir %{_topdir}/BUILD
# %_buildroot is where files get placed during the %install section of spec
# file processing prior to final packaging into rpms. This is oddly named
# and probably should have been called "%_installroot" back when it was
# initially added to RPM. Alas, it was not. ;o)
%_buildroot %{_topdir}/%{_tmppath}/%{name}-%{version}-root
# %_rpmdir is where binary RPM packages are put after being built.
%_rpmdir %{_topdir}/RPMS
# %_srcrpmdir is where src.rpm packages are put after being built.
%_srcrpmdir %{_topdir}/SRPMS
# %_rpmfilename defines the naming convention of the produced RPM packages,
# and should not be modified. It is listed here because I am overriding
# RPM's default behaviour of dropping binary RPM's each in their own
# separate subdirectories. I hate that. Grrr.
%_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
# Customized tags for local builds
# %packager is the info that will appear in the "Packager:" field in the
# RPM header on built packages. By default I have it read your username
# and hostname. This should be customized appropriately.
# %packager Joe Blow <joe at blow.com>
%packager %(echo ${USER}@)%(hostname)
%distribution LaRC/RTD/ESB Build
# GNU GPG config below
#%_signature gpg
#%_gpg_name Joe Blow <joeblow at somewhere.com>
#%_gpg_path %(echo $HOME)/.gnupg
# The following will try to create any missing directories required above
# (Not implemented yet)
# Change default RPM query format to show ARCH
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
[prs at wx1 ~]$ cat .rpmrc
include: /usr/lib/rpm/rpmrc
macrofiles: /usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:/etc/rpm/macros.specspo:/etc/rpm/macros:/etc/rpm/%{_target}/macros:~/.rpmmacros
[prs at wx1 ~]$ ll rpmbuild/
total 24
drwxr-xr-x 3 prs users 4096 Jul 29 17:52 BUILD
-rw-r--r-- 1 prs users 4491 Sep 9 2001 README
drwxr-xr-x 2 prs users 4096 Jul 29 17:55 RPMS
drwxr-xr-x 2 prs users 4096 Jul 29 17:55 SRPMS
drwxr-xr-x 2 prs users 4096 Jul 29 17:55 tmp
[prs at wx1 ~]$ cat rpmbuild/README
Building RPM packages as a non-root user.
by Mike A. Harris <mharris at redhat.com>
This document will teach you how to build RPM packages without
being logged in as the root user, which is unfortunately the
default in any new system installation.
Building packages logged in as "root" is a very very dangerous
thing to do. Many things can go wrong, and can actually destroy
files located throughout your system. Typos, and other errors
in RPM spec files, makefiles, etc. often produce unexpected results,
and that can lead to "very bad things(tm)" happening during
development.
Software development processes should never modify the build
environment they are using, nor overwrite installed system software.
As such, building RPM packages should never ever be done logged in
as root, but instead should be done by being logged into a regular
user account.
To start off with, you will need 3 things. The first is a custom
RPM config file (.rpmrc) in your home directory, and the second is
a custom RPM macrofile (.rpmmacros) also in your homedir. These
two files are included in this package. The .rpmrc should be used
as is, unless you really really really know what you are doing. The
.rpmmacros file can be tweaked to taste, but is useable by default.
These two files are copies of the exact configuration I use when
building packages for Red Hat Linux. Different developers each
have their own preferences however, so I urge everyone to play with
the config to find something that suits their needs.
These two files together tweak the locations of where RPM looks
for files when it is building packages, and where it places files
and scripts during building and packaging.
The third thing you need, is to create the directory structure
for building RPM packages. These dirs are completely configureable
via the .rpmmacros file, but RPM in general does not create them
for you if they do not exist. So if you change the dirs, make
absolutely sure that the new directories exist before testing.
My default supplied config uses a top level directory in your home
account "~/rpmbuild". All other directories are subdirectories
of the ~/rpmbuild directory.
SRPMS - where src.rpms get placed
RPMS - where all binary and noarch rpm packages get placed
BUILD - where software gets decompressed, patched and built
tmp - where the buildroot is and %install dumps files
The SOURCES and SPECS directories used by RPM in a default
installation of Red Hat Linux, I personally find irritating, as
I had to jump back and forth between two directories all the
time, and I found it very innefficient to work with. As such
I have merged the two into a single directory. This makes my
life so much easier it isn't even funny. ;o)
The other thing that annoys me about the default systemwide
RPM build environment is that if you have many many source
RPM packages installed, the SOURCES and SPECS directories were
huge steaming piles of random files that are impossible to
know which file came from which src.rpm package. Also, it is
possible 2 src.rpms might have the exact same filename contained
in them, but be different files. Ouch.
My solution was to have the sources for each package installed
into its own private per package-version directory. So when
you install a package ie: pine-4.33-15.src.rpm, it will be
placed into the directory: ~/rpmbuild/pine-4.33
This keeps each source package separate, and makes life a
highway.
I also hated RPM putting binary packages into RPMS/i386, RPMS/i686,
RPMS/alpha, RPMS/noarch, etc. GRRR!! So.. Now, instead of that,
ALL architectures are put into one single RPMS dir. Keep It Simple
Stupid! ;o)
I hope this RPM configuration is useful to other developers, and
makes life easier for you all as well. I am very much interested
in any feedback anyone may have from using these files, suggestions
for enhancement, etc.
Feel free to email me your suggestions for improvements. If you
have any problems with the configurations, I regret that I may
not be able to give individual assistance with configuring RPM or
tweaking these configurations as I am a very busy person usually.
Fortunately, Red Hat maintains a mailing list just for this
purpose, where you can ask for professional level help on RPM.
Please join the RPM mailing list if you have any questions about
customizing RPM, etc. To subscribe, send a message containing
the word "subscribe" to: rpm-list-request at redhat.com
Happy hacking!
TTYL