RPM is a complex system that helps manage thousands of packages for a complex operating system. Furthermore, RPM is very, very flexible. This flexibility makes it important that you follow the rules to create packages the proper way. Otherwise, you’ll face a host of problems with your RPMs. Following some best practices guidelines will help you avoid future problems as you release RPM updates.
This chapter covers ways to avoid common problems as well as best-practice guidelines for creating your own RPMs.
13.1. Avoiding Common Problems
Developers creating RPMs seem to hit many of the same roadblocks. This section covers some of the most common problems faced by RPM users and package builders.
Warning
Never, never, never build RPMs logged in as the root user. See the section on Building for details.
13.1.1. Scan the mailing lists
Many people have tried to solve a lot of serious problems that arise when using RPM, so if you are facing difficulties, chances are someone else has tackled those issues before. The RPM mailing list provides a technical forum for discussing RPM issues and problems. In many, if not most, cases, you can find answers to problems by scanning the mailing list archives.
You can also sign up for the mailing list so that you can send in requests and see the responses.
Cross Reference
If you are working with RPMs and pushing the envelope for other operating systems or complicated packages, this list is definitely worth a look.
Before sending any messages, though, be sure to look through the message archives to see if the message has already been answered. You will save time waiting for a response if you can get an archived response right away.
You should also ask any questions in a way that will generate the most helpful responses. This includes:
Do your homework first. Check to see if your question has already been answered by looking at the mailing list or newsgroup archives. In the end, this saves you the most time, as you don’t have to wait for answers.
Describe the problem and the symptoms as clearly as possible. After all, this is what you want help with.
Use clear subject headers. This is the first part of your message that people will read. If you are not clear, the key people who could answer your questions may never even read your message. And, if they don’t read the message, you will never get an answer.
Send your message in plain text, not HTML. Do not include a separate HTML copy of your message. This just makes it harder to read, especially for people who read collected digests of mailing lists.
Make it easy for people to reply to you. Include your email address in your message. You might want to include a line that states something like “Please send your reply to me at” and then provide your email address.
Cross Reference
These tips on asking questions come from the Internet document on How to Ask Questions the Smart Way by Eric Steven Raymond and Rick Moen, available at multiple sites, including www.owlriver.com/tips/smart.
In addition to the RPM mailing list, there is also a Usenet newsgroup, named linux.redhat.rpm. You can read this newsgroup with any newsreading program.
Note
Newsgroups are sometimes called discussion groups.
In older versions of RPM, you called the rpm –ba command to build RPMs. With RPM 4.1, you must use the rpmbuild command. If you have the rpmbuild command available, even if you are running an older version of RPM, run rpmbuild instead of rpm to build your RPMs.
You’d be surprised at how such a simple item is one of the most-asked questions on the RPM mailing list. That’s because the rpm –ba command, and the other –b options, no longer work in RPM 4.1. These options are supported by the rpmbuild command.
13.1.3. Don’t try to defeat the system
If you are finding your spec files getting more and more complex, and that you are trying to disable RPM features, chances are you are trying to defeat the system. This is not a good idea.
The RPM system works in a certain way. You may not always agree with the way it works, but if you try to make it work in contrary ways, in most cases you’ll end up fighting RPM to no avail.
There are certain rules, and more importantly certain conventions that RPMs should follow. The previous chapters in this section on building RPMs have outlined those conventions. Follow them. When you go against these conventions, you are really trying to defeat how the RPM system works.
13.1.4. Turn off automatic dependency generation
When you build an RPM, the rpmbuild command will automatically generate dependencies on Linux shared libraries and other system commands. You can turn this off if you need to, using a number of means.
You can disable the automatic generation of dependencies by placing the following directive in your spec file:
Autoreq: 0
A better approach, though, is to override the %{__find_requires} and %{__find_provides} macros, or just one of these as needed. You can null out either of these macros by adding commands like the following to your spec file:
%define __find_requires %{nil}
This approach is better because it allows you to override only the requires checks. In addition, you can get more specific and simply change how the automatic dependency checks are performed. For example, you can also change the definitions of these macros to perform normal dependency generation except for any problematic files or packages. These two macros resolve to shell scripts that perform the automated dependency checks, as you can see with the rpm --eval command:
$ rpm --eval "%__find_provides"
/usr/lib/rpm/find-provides
rpm --eval "%__find_requires"
/usr/lib/rpm/find-requires
You can override these scripts to filter out any dependencies that cause problems for your packages.
13.1.5. Don't list directories in %files
Unless you really mean it, don’t list directories in your %files section in your spec files. That is because the rpmbuild program will automatically add all files in that directory to your RPM. If this is a system directory, such as /usr/bin, your RPM has now claimed ownership for all the files, regardless of the source package.
To avoid all files in the directory becoming part of the package, list the files explicitly, perhaps generating the list of files as the program builds.
13.1.6. Handling circular dependencies
If two packages each depend on the other, you don’t want each package’s spec file to list the other in a Requires section. If this occurs, the packages won’t install without one of the force options, since each package will require the other to be installed first.
Cross Reference
Chapter 3, Using RPM covers how to install or upgrade packages while ignoring dependency checks. In general, you do not want to ignore these checks.
You can work around this issue by using the PreReq directive instead of Requires. For example, if package A depends on B and package B depends on A, you can place the following in the package B spec file:
PreReq: A
In addition, you can install both packages at the same time to avoid some of the problems with circular dependencies. Simply include both packages on the rpm –Uvh command line.
