|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| == BuildRequires == | | == BuildRequires == |
|
| |
|
| In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.
| | It is important that your package list all necessary build dependencies using the BuildRequires: tag. You may assume that enough of an environment exists for RPM to function and execute basic shell scripts, but you should not assume any other packages are present, as RPM dependencies and anything brought into the buildroot by the build system may change over time. |
| | |
| Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .
| |
| | |
| There are two suggested ways of detecting missing Build<code></code>Requires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[#rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more. <BR>
| |
| '''mock''' is another good way to check build dependencies. Rather than remove all developer packages, it tries to build your package in a chroot. It makes no changes to your normal, daily environment and ensures that your package will build fine. However, '''mock''' may need a good internet connection to download all required packages. [[Extras/MockTricks| MockTricks]] page contains more information. Another mock-like tool, '''mach''' is also available in the Fedora repository.
| |
| | |
| {{Anchor|Exceptions}}
| |
| | |
| === Exceptions ===
| |
| | |
| There is no need to include the following packages or their dependencies as Build<code></code>Requires because they would occur too often. These packages are considered the minimum build environment.
| |
| | |
| <pre>
| |
| bash
| |
| bzip2
| |
| coreutils
| |
| cpio
| |
| diffutils
| |
| fedora-release
| |
| findutils
| |
| gawk
| |
| gcc
| |
| gcc-c++
| |
| grep
| |
| gzip
| |
| info
| |
| make
| |
| patch
| |
| redhat-rpm-config
| |
| rpm-build
| |
| sed
| |
| shadow-utils
| |
| tar
| |
| unzip
| |
| util-linux
| |
| which
| |
| xz
| |
| </pre>
| |
|
| |
|
| === BuildRequires and %{_isa} === | | === BuildRequires and %{_isa} === |
Latest revision as of 22:53, 4 May 2015
BuildRequires
It is important that your package list all necessary build dependencies using the BuildRequires: tag. You may assume that enough of an environment exists for RPM to function and execute basic shell scripts, but you should not assume any other packages are present, as RPM dependencies and anything brought into the buildroot by the build system may change over time.
BuildRequires and %{_isa}
You MUST NOT use arched BuildRequires. The arch ends up in the built SRPM but SRPMs need to be architecture independent. For instance, if you did this:
# Example of what *not* to do
BuildRequires: python%{?_isa} >= 2.7
Then the SRPM that is built in Fedora would have one of these Requirements depending on what builder the SRPM was created on:
python(x86-32) >= 2.7
# or
python(x86-64) >= 2.7
This would prevent yum-builddep or similar tools that use the SRPM's requirements from operating correctly.
BuildRequires based on pkg-config
Fedora packages which use pkg-config to build against a library (e.g. 'foo') on which they depend, SHOULD express their build dependency correctly as pkgconfig(foo). For more information, see Packaging:PkgConfigBuildRequires.
