Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 16. Making a Package That Can Build Anywhere | Next |
Having RPM Use a Different Build Area
While RPM's build root requires a certain amount of spec file and make file tweaking in order to get it working properly, directing RPM to perform the build in a different directory is a snap. The hardest part is to create the directories RPM will use during the build process.
Setting up a Build Area
RPM's build area consists of five directories in the top-level:
The
BUILDdirectory is where the software is unpacked and built.The
RPMSdirectory is where the newly created binary package files are written.The
SOURCESdirectory contains the original sources, patches, and icon files.The
SPECSdirectory contains the spec files for each package to be built.The
SRPMSdirectory is where the newly created source package files are written.
The description of the RPMS directory above, is
missing one key point. Since the binary package files are specific to
an architecture, the directory actually contains one or more
subdirectories, one for each architecture. It is in these
subdirectories that RPM will write the binary package files.
|
That's all there is to it. You may have noticed that we created a
subdirectory to RPMS called
i386 — This is the architecture-specific
subdirectory for Intel x86-based systems, which is our example build
system.
The next step in getting RPM to use a different build area is telling RPM where the new build area is. And it's almost as easy as creating the build area itself.
Directing RPM to Use the New Build Area
rpmrc file. For the non-root user, this means
putting the following line in a file called
.rpmrc, located in your home directory:
|
<path> with the path to
the new build area's top-level directory, RPM will attempt to use it
the next time a build is performed. Using our newly created build
area as an example, we'll set topdir to
/home/ed/mybuild:
|
That's all there is to it. Now it's time to try a build.
Performing a Build in a New Build Area
cdplayer package in a personal build area. If
the user has modified rpmrc file entries to
change the default build area, the command used to start the build is
just like the one used by a root user. Otherwise, the
--buildroot option will need to be used:
|
Things started off pretty well — The %prep section of the spec file unpacked the sources into the new build area, as did the %build section. The build was proceeding normally in the user-specified build area, and root access was not required. In the %install section, however, things started to fall apart. What happened?
Take a look at that install command. The two options, "-o 0" and "-g 0", dictate that the directories to be created in the build root are to be owned by the root account. Since the user performing this build did not have root access, the install failed, and rightly so.
|
|
/usr/local/bin, so let's check
those:
|
Looks pretty good… Wait a minute! What's up with the owner and
group? The answer is simple: User ed ran the
build, which executed the make file, which ran
install, which created the files. Since
ed created the files, they are owned by him.
This brings up an interesting point. Software must be installed with very specific file ownership and permissions. But a non-root user can't create files that are owned by anyone other than his or herself. What is a non-root user to do?