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@wx1 ~]$ cat .rpmmacros # Custom RPM macros configuration file for building RPM packages # as a non-root user. # # Author: Mike A. Harris mharris@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@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@blow.com %packager %(echo ${USER}@)%(hostname) %distribution LaRC/RTD/ESB Build
# GNU GPG config below #%_signature gpg #%_gpg_name Joe Blow joeblow@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@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@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@wx1 ~]$ cat rpmbuild/README Building RPM packages as a non-root user. by Mike A. Harris mharris@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@redhat.com
Happy hacking! TTYL