Page 147
Why is it necessary to do all this checking? When would it be useful? Keep in mind that the %files list must be generated manually. By using the -bl option, the following steps are all that's necessary to create a %files list:
It may take more than one iteration through these steps, but eventually the list check will pass. Using the -bl option to check the %files list is certainly better than starting a two-hour package build, only to find out at the very end that the list contains a misspelled filename.
Here's an example of the -bl option in action:
# rpm -bl cdplayer-1.0.spec Package: cdplayer File List Check: cdplayer-1.0-1 Finding dependencies... Requires (2): libc.so.5 libncurses.so.2.0 #
It's hard to see exactly what RPM is doing from the output, but if we add -vv, we can get a bit more information:
# rpm -bl -vv cdplayer-1.0.spec D: Switched to BASE package D: Source(0) = sunsite.unc.edu:/pub/Linux/apps/sound/cds/cdplayer-1.0.tgz D: Switching to part: 12 D: fileFile = D: Switched to package: (null) D: Switching to part: 2 D: fileFile = D: Switching to part: 3 D: fileFile = D: Switching to part: 4 D: fileFile = D: Switching to part: 10 D: fileFile = D: Switched to package: (null) * Package: cdplayer File List Check: cdplayer-1.0-1 D: ADDING: /usr/doc/cdplayer-1.0-1 D: ADDING: /usr/doc/cdplayer-1.0-1/README D: ADDING: /usr/local/bin/cdp D: ADDING: /usr/local/bin/cdplay D: ADDING: /usr/local/man/man1/cdp.1 D: md5(/usr/doc/cdplayer-1.0-1/README) = 2c149b2fb1a4d65418131a19b242601c D: md5(/usr/local/bin/cdp) = 0f2a7a2f81812c75fd01c52f456798d6 D: md5(/usr/local/bin/cdplay) = d41d8cd98f00b204e9800998ecf8427e D: md5(/usr/local/man/man1/cdp.1) = b32cc867ae50e2bdfa4d6780b084adfa Finding dependencies... D: Adding require: libncurses.so.2.0 D: Adding require: libc.so.5 Requires (2): libc.so.5 libncurses.so.2.0 #
Page 148
Looking at this more verbose output, it's easy to see that there's a great deal going on. Some of it is not directly pertinent to checking the %files list, however. For example, the output extending from the first line to the line reading * Package: cdplayer reflects processing that takes place during actual package building and can be ignored.
Following that section is the actual %files list check. In this section, every file named in the %files list is checked to make sure it exists. The phrase ADDING: again reflects RPM's package building roots. When using the -bl option, however, RPM is simply making sure the files exist on the build system. If the --timecheck option (described a bit later, in section 12.1.14) is present, the checks required by that option are performed here, as well.
After the list check, the MD5 checksums of each file are calculated and displayed. While this information is vital during actual package building, it is not used when using the -bl option.
Finally, RPM determines which shared libraries the listed files require. In this case, there are only two: libc.so.5 and libncurses.so.2.0. While not strictly a part of the list-checking process, displaying shared library dependencies can be quite helpful at this point. It can point out possible problems, such as assuming that the target systems have a certain library installed when, in fact, they do not.
So far, we've only seen what happens when the %files list is correct. Let's see what happens where the list has problems. In this example, we've added a bogus file to the package's %files list:
# rpm -bl cdplayer-1.0.spec Package: cdplayer File List Check: cdplayer-1.0-1 File not found: /usr/local/bin/bogus Build failed. #
Reflecting more of its package building roots, rpm -bl says that the build failed. But the bottom line is that there is no such file as /usr/bin/bogus. In this example, we made the name obviously wrong, but in a more real-world setting, the name will more likely be a misspelling in the %files list. Okay, let's correct the %files list and try again:
# rpm -bl cdplayer-1.0.spec Package: cdplayer File List Check: cdplayer-1.0-1 File not found: /usr/local/bin/cdplay Build failed. #
Another error! In this case the file is spelled correctly, but it is not on the build system, even though it should be. Perhaps it was deleted accidentally. In any case, let's rebuild the software and try again:
# rpm -bi cdplayer-1.0.spec * Package: cdplayer Executing: %prep ...
Page 149
+ exit 0 Executing: %build ... + exit 0 Executing: %install ... ln -s /usr/local/bin/cdp /usr/local/bin/cdplay ... + exit 0 Executing: special doc ... + exit 0 # # rpm -bl cdplayer-1.0.spec Package: cdplayer File List Check: cdplayer-1.0-1 Finding dependencies... Requires (2): libc.so.5 libncurses.so.2.0 #
Done! The moral to this story is that using rpm -bl and fixing the error it flagged doesn't necessarily mean your %files list is ready for prime time: Always run it again to make sure!
Although it sounds dangerous, the --short-circuit option can be your friend. This option is used during the initial development of a package. Earlier in the chapter, we explored stopping RPM's build process at different stages. Using --short-circuit, we can start the build process at different stages.
One time that --short-circuit comes in handy is when you're trying to get software to build properly. Just think what it would be like—you're hacking away at the sources, trying a build, getting an error, and hacking some more to fix that error. Without --short-circuit, you'd have to do the following:
Pretty cumbersome! Since RPM's build process is designed to start with the sources in their original tar file, unless your modifications end up in that tar file, they won't be used in the next build. (As mentioned in Chapter 10, if the original sources need to be modified, the modifications should be kept as a separate set of patches. However, during development, it makes more sense to not generate patches every time a change to the original source is made.)