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. [1] 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.