In my last column, we learned the basics of RPM, the software management tool of Red Hat Enterprise Linux (and numerous other distributions). With a little less hand-holding this time, I am going to outline for you building a bigger SRPM project which has lots of dependencies. As scary as that may sound, it is really fairly simple in practice.
When you run that rpmbuild command on a spec file, one
of the first things to happen is checking to see if all the other stuff
it needs is already in place. Quite often, you'll get a message about
unsatisfied dependencies, followed by a nice indented list of what's
missing.
Sometimes you can Yum the missing stuff. Often not. So you chase down the SRPM for that thing, try to build it, and it too spits out its own list of unsatisfied dependencies. It can quickly go four layers deep, and more. It happened when I decided to build Pidgin from the SRPM. That's an older and still popular instant messaging client for the GNOME desktop. Most of the time, if you have any IM client installed at all, it's going to be called Empathy. I prefer Pidgin.
Let's recall some important pointers. You'll need to check in this order for sources:
So you install the Pidgin SRPM and attempt to run
rpmbuild on the SPEC file. You see a list something like
this:
avahi-glib-devel
farsight2-devel
gtkspell-devel
meanwhile-devel
NetworkManager-glib-develUntil you know better, you can try to Yum each one and see what
happens (yum install package). When I checked,
none were available. In some cases I had the base package, but not the
development ("-devel") version. That meant if I built the
SRPM, I had to decide whether it was an upgrade and install both the
base and devel, or if it was the same and install only the devel, or
something else it might produce, such as libs or utils or something with
a name which didn't match the SRPM at all. By trial and error I got it
done.
I'm going to outline the order and depth in which I proceeded. The number of dashes increase as they go deeper. After each item is the repo where I found it. An indentation below something indicates what I found required before I could proceed, until I got the item(s) farthest indented, and worked my way back up. Then I moved to the next item on the same level. Remember, most of the time the SRPM will be named for the base file, but will include any number of libs, devel, and assorted other files.
pidgin (RHEL)
- gtkspell-devel (RHEL)
- NetworkManager-glib-devel (RHEL)
-- wireless-tools-devel (RHEL Server)
-- libnl-devel (yum)
-- ppp-devel (RHEL)
--- libpcap-devel (RHEL)
---- bluez-libs-devel (RHEL)
----- gstreamer-plugins-base-devel (yum)
----- libsndfile-devel (FC13)
------ flac-devel (build broken, pulled from Beta Optional)
------ jack-audio-connection-kit-devel (yum)
----- libudev-devel (yum)
-- libuuid-devel (yum)
-- libgudev1-devel (yum)
-- gnome-bluetooth-libs-devel (RHEL from gnome-bluetooth)
--- unique-devel (yum)
- avahi-glib-devel (RHEL)
-- libdaemon-devel (RHEL)
-- libcap-devel (yum)
- meanwhile-devel (RHEL)
- farsight2-devel (with base & python, RHEL)
-- gstreamer-python-devel (RHEL)
-- libnice-devel (RHEL)
--- gupnp-igd-devel (RHEL)
---- gupnp-devel (RHEL)
----- gssdp-devel (RHEL)
You'll notice one item in particular -- flac-devel -- which would not build properly for me. I took a chance and checked the RHEL 6 Beta repository and found the package was the right version and didn't have to build from source. I simply installed that one as is. It may be the one and only time I can pull that stunt. You can find that repository here. Notice it is for the 32-bit version, so if you are running the 64-bit, you'll need to work your way back up the URL a few levels until you find the x86_64 stuff.
The sources I used will probably look different if you are working from CentOS or Scientific Linux. The obvious would be to replace RHEL with the source for your distro.
I once did something similar on the RHEL 6-Beta in order to gather all the stuff needed for full multimedia players and such. On the Beta-2 it didn't work so well. On the full release, it didn't work at all. The issue is all the exotic codecs I could only find at RPMFusion, and some of their SRPMs didn't match versions for dependencies. I'm not sure how they got out of sync, but it makes me uncomfortable using their repository any more.
For those of you running nVidia or Radeon video chipsets new enough that you don't have built-in full 3D acceleration on the display, you can use the above method for building something available, but not provided, in the RHEL RPM system. It's not necessary to go through the detailed and risky procedure for installing the special drivers provided by the chip manufacturers for Linux. When you use those drivers, some things don't quite work right because those drivers aren't properly integrated into the display server. Instead, you can install a package which is derived from the "mesa" SRPM.
Obtain the SRPM from the RHEL repositories, and go through the chase for dependencies for RPMbuild. One of the packages produced will be "mesa-dri-drivers-experimental," which will boost the acceleration for most Radeon and nVidia displays without nearly as much hassle. Just install that one package from the build. You don't have to kill Kernel Mode Setting (KMS) nor worry about minor display glitches showing up in some software. In the two beta releases for RHEL 6, this package was rickety and offered only a slight acceleration. In the full release, I got my Radeon HD 4350 to run plenty fast for everything I do on my system.
Ed Hurst is Associate Editor of Open for Business