Chapter 15. Making a Relocatable Package

RPM has the ability to give users some latitude in deciding where packages are to be installed on their systems. However, package builders must first design their packages to give users this freedom.

That's all well and good, but why would the ability to "relocate" a package be all that important?

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:

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.



Hey, we said it was hypothetical!


Of course, it would be possible to get around this lack of space by symlinking /opt to, for instance, /usr/opt. However, since the point of this chapter is to explore RPM's relocatability features, we won't explore this approach here.