Why relocatable packages?

One of the many problems that plague a system administrator's life is disk space. Usually, there's not enough of it, and if there is enough, chances are it's in the wrong place. Here's a hypothetical example:

• Some new software comes out and is desired greatly by the user community.

• The system administrator carefully reviews the software's installation documentation prior to doing to the installation.¹ She notes that the software, all 150MB of it, installs into /opt.

• Frowning, the sysadmin fires off a quick df command:

  # df
  Filesystem         1024-blocks  Used Available Capacity Mounted on
  /dev/sda0             100118   28434    66514     30%   /
  /dev/sda6             991995  365527   575218     39%   /usr
  #
  

  Bottom line: There's no way 150MB of new software is going to fit on the root filesystem.

• Sighing heavily, the sysadmin ponders what to do next. If only there were some way to install the software somewhere on the /usr filesystem...

It doesn't have to be this way. RPM has the ability to make packages that can be installed with a user-specified prefix that dictates where the software will actually be placed. By making packages relocatable, the package builder can make life easier for sysadmins everywhere. But what exactly is a relocatable package?

A relocatable package is a package that is standard in every way, save one. The difference lies in the prefix tag. When this tag is added to a spec file, RPM will attempt to build a relocatable package.

Note the word ``attempt''. There are a few conditions that must be met before a relocatable package can be built successfully, and this chapter will cover them all. But first, let's look at exactly how RPM can relocate a package. And the one component at the heart of package relocation is the prefix tag.