Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am running CentOS 5.5. I need to upgrade some packages to newer versions, unfortunately they're not available. I am stuck building from source.

Is there a simple way to use yum to manage something that I've built from source, so if a package does become available at a later point, I can uninstall the built-from-source version and replace it with the package?

share|improve this question
Why don't you package it yourself? – squarebear Jul 27 '13 at 20:25
up vote 4 down vote accepted

You sure you need the very last? Couldn't be backports?

It may be more easier just to install backports instead building from source. RHEL-based distros includes backports of security fixes by default. And nothing has to be done! You can check the security fixes using, i.e. rpm -q --changelog httpd | grep CVE for the httpd package. Consider reading this as why CentOS has seemingly older version of packages. Consider instead using some other distribution that uses bleeding edge if you don't like this feature, yes, it's a feature. Continue reading if you are aware of this.

Lets try not to break the system

Seems that from a look at different articles on the internet, you have to be specially cautious installing sources packages to a stable CentOS, since you are breaking the configuration of the system. Also you must never, EVER, build packages as root, because while building the package will try to install itself on the system, it's recommended in such case using two terminals, one for installing the tools using yum other for building packages. That said, lets break your system :D.


Before building any package, you need the correct sets of tools to do so (like anything else), so you must start downloading the basic set of tools for building form sources:

$ sudo yum groupinstall "Development Tools"
$ sudo yum install rpm-build

Some recent packages will need certain macros and scripts contained in redhat-rpm-config:

$ sudo yum install redhat-rpm-config

That said, depending of the package/source you are trying to build you may need more headers than this. A search of the specific build dependencies before hand should suffice.

Creating the Environment

The next step is to create the files and directories under your home directory that you need to build RPMs. As noted before, to avoid possible system libraries and other files damage, you should NEVER build an RPM with the root user. You should always use an unprivileged user for this purpose.

Now, lets create the directory structure in your home path:

 $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

And we need to write the ~/.rpmmacros, you should check that you don't have one or do a backup of your current one.

 $ echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

After this, your system should be ready to build most RPM packages without poking around anymore.

You still need more tools

Have you ever heard about make? Well, we haven't installed that just yet. So, lets put hands (fingers) to work:

$ sudo yum install make

Also, you may need some C libraries to build some packages done in... C?

# yum install gcc

As I said before, you may need even more libraries, but it dependences of the software you are building. Normally these files ends with -devel, so if the packages tells you it needs zlib you need to install zlib-devel.

The source package and creating the .spec

You must already have gotten your tar.gz file. If not, what are you waiting for!? Once you have gotten the sources, you must create your .spec file. This is the equivalent to the debian/* files in Debian-like systems, since they include the rules and information about the packages you are going to build.

Here is an example copied from somewhere:

# Example spec file for cdplayer app...
Summary: A CD player app that rocks!
Name: cdplayer
Version: 1.0
Release: 1
Copyright: GPL
Group: Applications/Sound
Source: ftp://ftp.gnomovision.com/pub/cdplayer/cdplayer-1.0.tgz
URL: http://www.gnomovision.com/cdplayer/cdplayer.html
Distribution: WSS Linux
Vendor: White Socks Software, Inc.
Packager: Santa Claus <sclaus@northpole.com>

It slices!  It dices!  It's a CD player app that
can't be beat.  By using the resonant frequency
of the CD itself, it is able to simulate 20X
oversampling.  This leads to sound quality that
cannot be equaled with more mundane software...

I think everything must be selfexplanatory up until here. But also here we should write the rules for building the package, the preparations, etc., but I'll try to make things easier for everybody so lets use macros:


In the previous lines %prep means preparations, and should be the actions to do before upgrading, installing the package. You can also make your own rules manually, but lets be sincere, is a pain. Since we have ended with this, next section is %build, pretty easy to know what happens here ;)


You can personalize this section as you see fit, using BUILD_PARAMETERS="--some-switch", this of course, depends of your source package. Now the %install section:

make install

No rocket science here. So just a section left, %files:


This section list all the files to be included in the package, if you don't set this section, the package will be effectively empty! The %doc stands for documentation... you already knew that. Now, how to select the files to be included in the %files section? Lets quote:

Since the majority of an application's files are installed by its makefile, RPM has no control over that part of the build process, and therefore, cannot automatically determine which files should be part of the package. Some people have attempted to use a modified version of install that logs the name of every file it installs. But not every makefile uses install, or if it does, uses it sporadically.

Another approach tried was to obtain a list of every file on the build system, immediately before and after a build, and use the differences as the file list. While this approach will certainly find every file that the application installed, it can also pick up extraneous files, such as system logs, files in /tmp, and the like. The only way to begin to make this approach workable would be to do nothing else on the build system, which is highly inconvenient. This approach also precludes building more than one package on the system at any given time.

At present, the best way to create the file list is to read the makefile to see what files it installs, verify this against the files installed on the build system, and create the list.

Is up to you how you do :).


Well, you already have a somewhat simple .spec file that could work. But, the world isn't rose and in some situations this won't work, so you may need more complex building steps. I've found this guide quite easy to follow, and might come helpful to you.


share|improve this answer
+1. Very thorough. – Evan Teitelman Jul 27 '13 at 21:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.