Библиотека сайта или "Мой Linux Documentation Project"
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 13. Inside the Spec File||Next|
The %files list may contain a number of different directives. They are used to:
Identify documentation and configuration files.
Ensure that a file has the correct permissions and ownership set.
Control which aspects of a file are to be checked during package verification.
Eliminate some of the tedium in creating the %files list.
bazin the following manner:
Now it's time to take a look at the directives that inhabit the %files list.
RPM processes files differently according to their type. However, RPM does not have a method of automatically determining file types. Therefore, it is up to the package builder to appropriately mark files in the %files list. This is done using one of the directives below.
Keep in mind that not every file will need to be marked. As you read the following sections, you'll see that directives are only used in special circumstances. In most packages, the majority of files in the %files list will not need to be marked.
README exists in the software's
top-level directory during the build, and is included in the package
file. When the package is installed, RPM creates a directory in the
documentation directory named the same as the package (ie,
and copies the
README file there. The newly
created directory and the
README file are
marked in the RPM database as being documentation. The default
documentation directory is
/usr/doc, and can be
changed by setting the defaultdocdir
rpmrc file entry. For more information on
rpmrc files, please see Appendix B.
/usr/local/foonly/README was installed
into that directory during the build and is included in the package
file. When the package is installed, the
README file is copied into
/usr/local/foonly and marked in the RPM
database as being documentation.
The %config directive is used to flag the specified file as being a configuration file. RPM performs additional processing for config files when packages are erased, and during installations and upgrades. This is due to the nature of config files: They are often changed by the system administrator, and those changes should not be lost.
Note that the full path to the file, as it is installed at build time, is required.
The %attr directive permits finer control over three key file attributes:
The file's permissions, or "mode".
The file's user ID.
The file's group ID.
foo.bar's permissions to 755. The file would be owned by user root, group root. If a particular attribute does not need to be specified (usually because the file is installed with that attribute set properly), then that attribute may be replaced with a dash:
The main reason to use the %attr directive is to permit users without root access to build packages. The techniques for doing this (and a more in-depth discussion of the %attr directive) can be found in Chapter 16.
RPM's ability to verify the integrity of the software it has installed is impressive. But sometimes it's a bit too impressive. After all, RPM can verify as many as nine different aspects of every file. The %verify directive can control which of these file attributes are to be checked when an RPM verification is done. Here are the attributes, along with the names used by the %verify directive:
MD5 Checksum (md5)
Major Number (maj)
Minor Number (min)
Symbolic Link String (symlink)
Modification Time (mtime)
We've left out owner and group, since we'd rather RPM not verify those. 
This use of %verify produces identical results to the previous example.
While the two directives in this section perform different functions, each is related to directories in some way. Let's see what they do:
The %docdir directive is used to add a directory
to the list of directories that will contain documentation. RPM
includes the directories
the %docdir list by default.
/usr/blatherwill be included in the package as usual, but will also be automatically flagged as documentation. This directive is handy when a package creates its own documentation directory and contains a large number of files. Let's give it a try by adding the following line to our spec file:
/usr/blatherdirectory. After building the package, looking at the package's file list shows:
Wait a minute: There's nothing there, not even
/usr/blather! What happened?
The problem is that %docdir only directs RPM to mark the specified directory as holding documentation. It doesn't direct RPM to package any files in the directory. To do that, we need to clue RPM in to the fact that there are files in the directory that must be packaged.
INSTALLhas indeed been marked as documentation, even though the %doc directive had not been used:
/usr/blatheras being documentation, and the second line tells RPM to automatically package any files found in
/usr/blather, every single file in there will be packaged and marked as documentation:
The %docdir directive can save quite a bit of effort in creating the %files list. The only caveat is that you must be sure the directory will only contain files you want marked as documentation. Keep in mind, also, that all subdirectories of the %docdir'ed directory will be marked as documentation directories, too.
As we mentioned in the section called The %files List, if a directory is specified in the %files list, the contents of that directory, and the contents of every directory under it, will automatically be included in the package. While this feature can be handy (assuming you are sure that every file under the directory should be packaged) there are times when this could be a problem.
The way to get around this, is to use the %dir directive. By adding this directive to the line containing the directory, RPM will package only the directory itself, regardless of what files are in the directory at the time the package is created. Here's an example of %dir in action.
blather-1.0package creates the directory
/usr/blatheras part of its build. It also puts several files in that directory. In the spec file, the
/usr/blatherdirectory is included in the %files list:
/usr/blatheras part of their path. After building the package, we use RPM to look at the files in the package:
The files present in
/usr/blather at the time
the package was built were included in the package automatically,
without entering their names in the %files list.
/usr/blatherline in the %files list to:
The -f option is used to direct RPM to read the %files list from the named file. Like the %files list in a spec file, the file named using the -f option should contain one filename per line and also include any of the directives named in this section.
Why is it necessary to read filenames from a file rather than have the filenames in the spec file? Here's a possible reason:
The filenames' paths may contain a directory name that can only be determined at build-time, such as an architecture specification. The list of files, minus the variable part of the path, can be created, and sed can be used at build-time to update the path appropriately.
Here, the filenames present in the file
tetex-latex-skel would be packaged, followed by
every filename following the %files line.
RPM will automatically exclude file attributes from verification if it doesn't make sense for the type of file. In our example, getting the MD5 checksum of a device file is an example of such a situation.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.