Библиотека сайта или "Мой Linux Documentation Project"
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 13. Inside the Spec File||Next|
While the "exclude" and "exclusive" tags (excludearch, exclusivearch, excludeos, and exclusiveos) provide some control over whether a package will be built on a given architecture and/or operating system, that control is still rather coarse.
For example, what should be done if a package will build under multiple architectures, but requires slightly different %build scripts? Or what if a package requires a certain set of files under one operating system, and an entirely different set under another operating system? The architecture and operating system-specific tags we've discussed earlier in the chapter do nothing to help in such situations. What can be done?
One approach would be to simply create different spec files for each architecture or operating system. While it would certainly work, this approach has some problems:
More work. The existence of multiple spec files for a given package means that the effort required to make any changes to the package is multiplied by however many different spec files there are.
More chance for mistakes. If any work needs to be done to the spec files, the fact they are separate means it is that much easier to forget to make the necessary changes to each one. There is also the chance of introducing mistakes each time changes are made.
The other approach is to somehow permit the conditional inclusion of architecture- or operating system-specific sections of the spec file. Fortunately, the RPM designers chose this approach, and it makes multi-platform package building easier and less prone to mistakes.
We discuss multi-platform package building in depth in Chapter 19. For now, let's take a quick look at RPM's conditionals.
The problem that surfaced here is that any conditional must be "closed" by using either %else or %endif. We'll be covering them a bit later in the chapter.
The %ifnarch conditional is used in a similar fashion to %ifarch, except that the logic is reversed. If a spec file contains a conditional block starting with %ifarch alpha, that block would be processed only if the build was being done on a Digital Alpha/AXP-based system. However, if the conditional block started with %ifnarch alpha, then that block would be processed only if the build were not being done on an Alpha.
Like %ifarch, %ifnarch can be followed by one or more architectures and must be closed by a %else or %endif.
The contents of the spec file following this line would be processed only if the build was done on a linux system.
The %ifnos conditional is the logical complement to %ifos: that is, if a conditional starting with the line %ifnos irix is present in a spec file, then the file contents after the %ifnos will not be processed if the build system is running Irix. As always, a conditional block starting with %ifnos must be closed by a %else or %endif.
When a build is performed on a Digital Alpha/AXP, some additional flags are added to the make command. On all other systems, these flags are not added.
In this example, we see the conditional block started with a %ifarch and ended with a %endif.
Now that we have some more in-depth knowledge of the spec file, let's take a look at some of RPM's additional features. In the next chapter, we'll explore how to add dependency information to a package.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.