Библиотека сайта или "Мой Linux Documentation Project"
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 16. Making a Package That Can Build Anywhere||Next|
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.
RPM's build area consists of five directories in the top-level:
BUILDdirectory is where the software is unpacked and built.
RPMSdirectory is where the newly created binary package files are written.
SOURCESdirectory contains the original sources, patches, and icon files.
SPECSdirectory contains the spec files for each package to be built.
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
i386 — This is the architecture-specific
subdirectory for Intel x86-based systems, which is our example build
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.
rpmrcfile. 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
That's all there is to it. Now it's time to try a build.
cdplayerpackage in a personal build area. If the user has modified
rpmrcfile 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?
Только зарегистрированные пользователи могут оценивать и комментировать статьи.