Rebuild a Source RPM
This document will guide you on how to rebuild a Source RPM (SRPM) package on your CentOS distribution.
One of the reasons why you may want to do this is to install a software package that is not available in CentOS repositories. Even if the software is not available in CentOS, you should always try to get or build a RPM for the software, since the advantages of using a package management system will compensate for the work you will have building the package. There are considerable benefits to using a package management system to manage dependencies versus source installs. After building packages you may want to consider setting up a local repo to simplify package management using yum or GUI tools.
1. Do You Really Need to Rebuild?
First consider the burden that rebuilding a SRPM will be for you. You will have to maintain it and rebuild it every time that security updates are available. Before deciding to rebuild a SRPM, you should probably look for the desired package in one of the available Repositories to see if they already contain the package you seek.
Most people using repositories expect support (mailing list, fora, bug tracker, IRC channel), and an archive which issues security and feature updates on the packages it provides. Most of the sources listed in the 'Repositories' wiki page have such resources and features, but some do not. For instance, the CentOS 'testing' archive is one that does NOT seek to expressly provide an update path. Only packages signed with the relevant CentOS GPG key are products of the CentOS project.
2. Where to Get SRPM Packages
The chance of success in rebuilding a SRPM package largely depends on how close the distribution is to CentOS. For example, it is almost certain that you will have success in rebuilding Red Hat or CentOS packages for the same major version. You may want to look for SRPMs from other distros based on Red Hat, such as Scientific Linux, since they will tend to be compatible with the CentOS base packages. As Red Hat (and consequently CentOS) is partially based on a stabilized subset of Fedora, it is often possible to rebuild SRPMs from Fedora in CentOS. The chance of rebuilding SRPMs for a higher version of Red Hat or CentOS is fairly good, the chance of rebuilding SRPMs from Fedora Core 6 or Fedora 7 on CentOS-5 is quite good, but the chances of rebuilding those from later Fedora versions is lower, as they have diverged considerably from the EL5 branch point during FC6 test versions. Some SRPMs up to Fedora 11 may rebuild on CentOS-5 without problems but those from Fedora 11 and later currently require use of the "--nomd5" flag with the rpm command to install. For CentOS-6 the corresponding Fedora versions are 12/13, the approximate versions from which EL6 was forked, and many Fedora 14 and above SRPMs will build successfully. The chance of rebuilding SRPMs made for other divergent RPM-based distributions, such as Mandriva or SuSE, without substantial changes is medium to low. Finally, some distribution-independent open source software is available in the form of SRPMs. You may be able use these instructions to rebuild those SRPMs on your system.
When rebuilding SRPMs, you will probably have more chance of success for packages that are add-ons to the system, rather than for core packages. If dependencies for an SRPM you are trying to rebuild require updating core packages it is probably time to look for an older SRPM as a starting point. You should probably not try to use this procedure to upgrade glibc, gcc, python, perl, or other core system components to a later version. If you do that, you risk damaging your system in a way that may be hard to recover from.
If you are trying to fix a bug that is fixed on the upstream but still not fixed in CentOS (usually this window is small) you may want to look for SRPMs that are made available by the upstream vendor:
Otherwise, you may look for SRPMs for CentOS for a more recent version than the one you are running. For instance, it is often possible to rebuild SRPMs for CentOS 5 in a CentOS 4 machine. CentOS SRPMs are available at:
Once you locate the SRPM file, you can download it to your machine using wget or the browser itself. You may save the file to any directory. Although you may save it to the SRPMS directory in your RPM building tree, you should probably avoid that since the file may end up being overwritten when you build the RPM again.
Note: Although you may have success with rebuilding and using SRPMs from other distros, it is not guaranteed that you will. You should be aware that you may even damage your system in a way that is hard to recover by installing rebuilt RPMs from other distros. To be safe try to stick to packages included in CentOS, or in the recommended additional Repositories as much as possible. Remember, if you break it, you get to keep all the pieces.
3. Prepare the RPM Building Environment
Follow these instructions to set up your environment to build RPMs.
4. Rebuild the SRPM in One Step
The quickest way to rebuild the SRPM is to use the rpmbuild --rebuild ... command. This command will unpack the SRPM file into the specfile and the source files, and then it will build the RPM from the instructions on the specfile.
|
For example, to rebuild the /tmp/mypackage-1.0.0-1.src.rpm package, run this command:
[user@host ~]$ rpmbuild --rebuild /tmp/mypackage-1.0.0-1.src.rpm
If everything goes right, you will end up with a mypackage-1.0.0-1.i386.rpm file under the ~/rpmbuild/RPMS/i386 directory (if your architecture is i386, otherwise the name of the file and the directory will change accordingly).
If something goes wrong during the rebuild of the RPM, the error message should give you a hint of what went wrong and needs to be fixed. Often the problem is that you do not have all the tools needed to rebuild the RPM available. See here for a list of some tools that are usually needed when building RPMs. Sometimes the BuildRequires may need to be adjusted for changed package names or versions, or to add requirements that have been inadvertently omitted from the spec file.
5. Install the SRPM and then Build from the Specfile
Another alternative is to first install the files from the SRPM and then use rpmbuild to rebuild from the specfile. This is required for Fedora >= 11 RPMS.
To install a SRPM, you run the rpm -i command with the SRPM package as an argument. Note that you run rpm -i with your unprivileged user, not with root. You can also use rpm -qpl to list the files contained inside the SRPM package. When you install a SRPM package, the specfile (the one with the .spec extension) will be placed in your ~/rpmbuild/SPECS directory, and all other files contained in the SRPM (usually source tarballs and patches) will be placed in your ~/rpmbuild/SOURCES directory. For example, to unpack the contents of the /tmp/mypackage-1.0.0-1.src.rpm package, run this command:
[user@host ~]$ rpm -i /tmp/mypackage-1.0.0-1.src.rpm
For later Fedora RPMS, or any that produce an error like "error: unpacking of archive failed on file /builddir/build/SOURCES/mypackage-1.0.0.tar.gz;4dc983a7: cpio: MD5 sum mismatch":
[user@host ~]$ rpm --nomd5 -i /tmp/mypackage-1.0.0-1.src.rpm
Once you unpacked the SRPM, you will notice that now there is a specfile (in this case, it will typically be called mypackage.spec) in the ~/rpmbuild/SPECS directory. That is the file you will use to build the RPM. To do that, use the following command:
[user@host ~]$ cd ~/rpmbuild/SPECS [user@host SPECS]$ rpmbuild -ba mypackage.spec
The rpmbuild -ba command will run through all the steps of the RPM building process, and at the end it will create an RPM package file (which will be saved under ~/rpmbuild/RPMS/i386, or the directory appropriate for your architecture), and also a new SRPM file (which will be saved under ~/rpmbuild/SRPMS).
The advantage of unpacking the SRPM first and then using rpmbuild -ba to rebuild it from the specfile is that you can modify the specfile (and maybe add some patches or even upgrade the source tarball) to suit your needs. This is a more complex situation than just rebuilding the SRPM, though, and if you are going down this route you should probably read more on the subject, as explained below, but the process goes like this:
- cd ~/rpmbuild/SPECS/
- rpmbuild -bp mypackage.spec
- cd ~/rpmbuild/BUILD/
- cp existing_directory existing_directory.orig
- cd existing_directory
- find the file you wish to change, modify it.
- cd ~/rpmbuild/BUILD/
diff -Npru existing_directory.orig existing_directory > name_of_your_patch_file.patch
- cp name_of_your_patch_file.patch ~/rpmbuild/SOURCES/
- cd ~/rpmbuild/SPECS/
- edit the mypackage.spec file to add the definition of name_of_your_patch_file.patch and the application of your_patch_file -- please look in the file to see how that is done.
- rpmbuild -ba mypackage.spec
These are excellent resources to help you if you decide to customize a specfile to your needs: