Chapter 15

Making a Relocatable
Package

RPM has the capability 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?

15.1. 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 the installation. (Hey, we said it was hypothetical!) 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. When a prefix tag is added to a spec file, RPM will attempt to build a relocatable package.

Note the word attempt. A few conditions must be met before a relocatable package can be built successfully, and this chapter covers them all. But first, let's look at exactly how RPM can relocate a package.

15.2. The prefix tag: Relocation Central

The best way to explain how the prefix tag is used is to step through an example. Here's a sample prefix tag:

Prefix: /opt

In this example, the prefix path is defined as /opt. This means that, by default, the package will install its files under /opt. Let's assume that the spec file contains the following line in its %files list:

/opt/bin/baz

If the package is installed without any relocation, this file will be installed in /opt/bin. This is identical to how a nonrelocatable package is installed.

However, if the package is to be relocated on installation, the path of every file in the %files list is modified according to the following steps:

1. The part of the file's path that corresponds to the path specified on the prefix tag line is removed.
2. The user-specified relocation prefix is prepended to the file's path.

Using our /opt/bin/baz file as an example, let's assume that the user installing the package wishes to override the default prefix (/opt) with a new prefix, say /usr/local/opt. Following the previous steps, we first remove the original prefix from the file's path:

/opt/bin/baz becomes /bin/baz

Next, we add the user-specified prefix to the front of the remaining part of the filename:

/usr/local/opt + /bin/baz = /usr/local/opt/bin/baz

Now that the file's new path has been created, RPM installs the file normally. This part of it seems simple enough, and it is. But as mentioned earlier, there are a few things the package builder needs to consider before getting on the relocatable package bandwagon.

15.3. Relocatable Wrinkles: Things to Consider

While it's certainly no problem to add a prefix tag line to a spec file, it's necessary to consider a few other issues:

• Every file in the %files list must start with the path specified on the prefix tag line.
• The software must be written such that it can operate properly if relocated. Absolute symlinks are a prime example of this.
• Other software must not rely on the relocatable package being installed in any particular location.

Let's cover each of these issues, starting with the %files list.

15.3.1. %files List Restrictions

As mentioned earlier, each file in the %files list must start with the relocation prefix. If this isn't done, the build will fail:

# rpm -ba cdplayer-1.0.spec

* Package: cdplayer

+ umask 022

+ echo Executing: %prep

...

Binary Packaging: cdplayer-1.0-1

Package Prefix = usr/local

File doesn't match prefix (usr/local): /usr/doc/cdplayer-1.0-1

File not found: /usr/doc/cdplayer-1.0-1

Build failed.

#

In our example, the build proceeded normally until the time came to create the binary package file. At that point RPM detected the problem. The error message says it all: The prefix line in the spec file (/usr/local) was not present in the first part of the file's path (/usr/doc/
cdplayer-1.0-1). This stopped the build in its tracks.

The fact that every file in a relocatable package must be installed under the directory specified in the prefix line raises some issues. For example, what about a program that reads a configuration file normally kept in /etc? This question leads right into our next section.

15.3.2. Relocatable Packages Must Contain Relocatable Software

While this section's title seems pretty obvious, it's not always easy to tell if a particular piece of software can be relocated. Let's take a look at the question raised at the end of the previous section. If a program has been written to read its configuration file from /etc, there are three possible approaches to making that program relocatable:

• Set the prefix to /etc and package everything under /etc.
• Package everything somewhere other than /etc and leave out the config file entirely.
• Modify the program.

The first approach would certainly work from a purely technical standpoint, but not many people would be happy with a program that installed itself in /etc. So this approach isn't viable.

The second approach might be more appropriate, but it forces users to complete the install by having them create the config file themselves. If RPM's goal is to make software easier to install and remove, this is not a viable approach either!

The final approach might be the best. Once the program is installed, when the rewritten software is first run, it can see that no configuration file exists in /etc and create one. However, even though this would work, when the time came to erase the package, the config file would be left behind. RPM had never installed it, so RPM couldn't get rid of it. There's also the fact that this approach is probably more labor intensive than most package builders would like.