initCommon(); $template->displayHeader(); ?>

9.5. Filling the List of Files

The %files section holds a list of all the files that RPM should install from the package. This list should be exhaustive, so that the RPM system knows exactly what your package installs. There are some options, though, to name all the files within a directory to help with packages containing hundreds of files.

In the default case, each line under the %files section names a separate file with its full path. For example:

%files

/usr/X11R6/bin/xtoolwait

/usr/X11R6/man/man1/xtoolwait.1

This example lists two files, /usr/X11R6/bin/xtoolwait and /usr/X11R6/man/man1/xtoolwait.1, presumably an online manual files.

9.5.1. Using wildcards

In addition to naming each file on a line, you can use glob-style wildcards. For example:

%files

/usr/X11R6/bin/xtoolwait

/usr/X11R6/man/man1/xtoolwait.*

This example states that all files in /usr/X11R6/man/man1 that start with xtoolwait. should be included in the package.

9.5.2. Naming directories of files

In addition to using wildcard globs, you can specify whole directories as part of your package. For example:

%files

/usr/X11R6/bin/xtoolwait

/etc/xtoolwait

This example names all the files in the directory /etc/xtoolwait as part of the package. Be very careful when listing this directory. Do not include a system directory such as /usr/bin, as RPM will assume your package owns all of /usr/bin, which contains hundreds of commands. This can be a problem when you try to remove a package.

It is OK to name a subdirectory that your package owns. For example, while /etc is a system directory, /etc/xtoolwait is a reasonable directory for the xtoolwait package to control.

If you just want to include an empty directory in the package, and not the files within the directory, use the %dir directive in front of the directory name. For example:

%files

/usr/X11R6/bin/xtoolwait

%dir /etc/xtoolwait

This example states that the package contains the /usr/X11R6/bin/xtoolwait program and the empty directory /etc/xtoolwait.

In addition to the straight list of files or directories, RPM provides other options, starting with marking certain files as documentation or configuration files.

9.5.3. Marking files as documentation or configuration files

RPM keeps special track of files within a package that hold documentation or configuration data. You need to identify these files with special directives.

The %doc directive marks a file as a documentation file. For example:

%files

/usr/X11R6/bin/xtoolwait

%doc /usr/X11R6/man/man1/xtoolwait.*

This example lists all the included files in /usr/X11R6/man/man1 as documentation files.

If you don’t include the full path to a documentation file or files, the RPM system will create a special documentation directory for the package, and place those files into that directory. For example:

%doc README NEWS

This example places the files README and NEWS into a newly created package-specific directory, typically a subdirectory under /usr/share/doc or /usr/doc.

The %docdir directive names a directory that holds documentation. All files under that directory in the package will get automatically marked as documentation files. For example:

%files

/usr/X11R6/bin/xtoolwait

%docdir /usr/X11R6/man/man1

/usr/X11R6/man/man1/xtoolwait.*

Note

In addition to the marked directories, the standard Linux documentation directories, such as /usr/share/man, are automatically assumed to be documentation directories.

Similar to the %doc directive, the %config directive marks a file as configuration. For example:

%files

/sbin/ypbind

%config /etc/rc.d/init.d/*

%config /etc/yp.conf

%doc README NEWS

A special option to the %config directive, noreplace, tells RPM not to overwrite, or replace a configuration file. For example:

%files

/sbin/ypbind

%config /etc/rc.d/init.d/*

%config(noreplace) /etc/yp.conf

%doc README NEWS

Use this option to help protect local modifications. If you use %config(noreplace), the file will not overwrite an existing file that has been modified. If the file has not been modified on disk, the rpm command will overwrite the file. But, if the file has been modified on disk, the rpm command will copy the new file with an extra file-name extension of .rpmnew.

Similarly, %config(missingok) means that the file does not have to exist on disk. You can use this modifier for files or links that are created during the %post scripts but will need to be removed if the package is removed.

Another special modifier, %ghost, tells the rpm command that the file should not be included in the package. You can use this to name the needed attributes for a file that the program, when installed, will create. For example, you may want to ensure that a program’s log file has certain attributes.

9.5.4. Setting file attributes

When your package is installed, you can control the file attributes as well as the files that get included into the package. This is very useful since most packages are installed by the root user and you don’t always want the root user owning the files.

The %attr directive allows you to control the permissions for a particular file. The format is:

%attr(mode, user, group) filename

For example:

%attr(0644, root, root) /etc/yp.conf

This example sets the file permissions to 644, the user and the group to root. If you don’t need to specify a value, use a dash, -, to leave the setting as is for the file. For example:

%attr(-, root, -) /etc/yp.conf

Note that you can combine directives, one after another. For example:

%config %attr(-, root, -) /etc/yp.conf

You can also use spaces instead of commas as delimiters. For example:

%attr(0700 root root) %dir /var/tux

In addition to using %attr to set the attributes for a file, you should use the %defattr directive to set the default attributes for all files in the package. For example:

%files

%defattr(-,root,root)

/usr/X11R6/bin/xtoolwait

/usr/X11R6/man/man1/xtoolwait.*

Just about every spec file uses the %defattr directive as this directive eliminates a lot of work you need to do to set file attributes individually. In addition, using the %defattr directive is considered a best practice when creating packages.

You can also mark files for a particular language. For example, from the tcsh shell package:

%files

%defattr(-,root,root)

%doc FAQ Fixes NewThings complete.tcsh eight-bit.txt tcsh.html

%{_bindir}/tcsh

%{_bindir}/csh

%{_mandir}/*/*

%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*

%lang(el) %{_datadir}/locale/el/LC_MESSAGES/tcsh*

%lang(en) %{_datadir}/locale/en/LC_MESSAGES/tcsh*

%lang(es) %{_datadir}/locale/es/LC_MESSAGES/tcsh*

%lang(et) %{_datadir}/locale/et/LC_MESSAGES/tcsh*

%lang(fi) %{_datadir}/locale/fi/LC_MESSAGES/tcsh*

%lang(fr) %{_datadir}/locale/fr/LC_MESSAGES/tcsh*

%lang(it) %{_datadir}/locale/it/LC_MESSAGES/tcsh*

%lang(ja) %{_datadir}/locale/ja/LC_MESSAGES/tcsh*

%lang(pl) %{_datadir}/locale/pl/LC_MESSAGES/tcsh*

%lang(ru) %{_datadir}/locale/ru/LC_MESSAGES/tcsh*

%lang(uk) %{_datadir}/locale/uk/LC_MESSAGES/tcsh*

This example marks certain files as only being of use with particular languages, such as ja for the Japanese text and fr for the French text.

9.5.5. Verifying the %files section

You can use the %verify directive to control which tests RPM uses when verifying a package.

Cross Reference

See Chapter 5 for more on package verification.

The %verify directive names the tests to include or not include. Table 10-4 lists the tests.

Table 10-4 Package verification tests

Test

Usage

group

Verifies the group of the file

maj

Verifies the file’s major device number

md5

Verifies the file’s MD5 checksum

min

Verifies the file’s minor device number

mode

Verifies the file mode, or permissions

mtime

Verifies the file’s last modification time

owner

Verifies the owner of the file

size

Verifies the file’s size

symlink

Verifies a symbolic link

With the %verify directive, you can name test, such as shown following:

%verify(owner group size) /etc/yp.conf

This example limits the tests to owner, group, and size. (The default is to perform all the tests.) You can also use the word not to specify that RPM should not run one or more tests. For example:

%verify(not owner) /etc/yp.conf

This example turns off just the owner test.

9.5.6. Filling the list of files automatically

The -f option to the %files section allows you to read in a list of file names from a file. This file is assumed to look like the contents of the %files section, holding one file name per line. You can also include the various directives for files such as %attr or %doc. For example:

%files -f list_of_filenames.txt

You can combine this list with filename entries, such as the following:

%files -f xconfig_files.txt

%defattr(-,root,root)

/usr/X11R6/bin/xtoolwait

/usr/X11R6/man/man1/xtoolwait.1

This example reads in a list of file names from the file named xconfig_files.txt and also includes two additional files.

This list of files works best if you cannot determine the file names in advance. The build may create different files based on various macro values. In addition, you may not know the final paths for the files until build time.

9.5.7. Handling RPM build errors for unpackaged files

Starting with RPM 4.1, rpmbuild will exit if all files in the $RPM_BUILD_ROOT directory are not found in the %files section (or in a file that lists file names used with the -f option). This is officially known as a Fascist build policy and you can turn it off with the following macros.

The %_unpackaged_files_terminate_build macro, if set to 1, tells rpmbuild to exit if it finds files that are in the $RPM_BUILD_ROOT directory but not listed as part of the package. Set this macro to 0 to turn off the Fascist build policy. For example:

%define _unpackaged_files_terminate_build 0

You can also control the flag that specifies whether missing documentation files cause rpmbuild to exit. Set the %_missing_doc_files_terminate_build macro to 0 to turn off this feature:

%define _missing_doc_files_terminate_build 0

See the "Defining Spec File Macros" section later in the chapter for more on using macros.

Cross Reference

You can also store this setting in a macro file so that it applies for all packages you build. See Chapter 21 for more on macro files.

While the Fascist build policy may be an annoyance, it can prove very useful. Chances are your spec file has an error if you have files in the $RPM_BUILD_ROOT directory that are not listed in the %files section. The Fascist build policy helps catch these errors. In addition, since the error outputs a list of files in the $RPM_BUILD_ROOT directory that are not listed in the %files section, you can often paste this list into your %files section.

displayFooter('$Date: 2005/11/02 19:30:06 $'); ?>