Where is rpm build root defined

The functionality requires the text file to be marked as executable. This section shows how to compile the pello. Python source code can also be raw-interpreted, but the byte-compiled version is faster. Hence, RPM Packagers prefer to package the byte-compiled version for distribution to end users.

Python is often byte-compiled, but not in the way described here. The following procedure aims not to conform to the community standards, but to be simple.

For real-world Python guidelines, see Software Packaging and Distribution. This section shows how to raw-interpret the bello program written in the bash shell built-in language.

Programs written in shell scripting languages, like bash , are raw-interpreted. In RPM packaging, instead of modifying the original source code, we keep it, and use patches on it. A patch is a source code that updates other source code. It is formatted as a diff , because it represents what is different between two versions of the text. A diff is created using the diff utility, which is then applied to the source code using the patch utility.

Software developers often use Version Control Systems such as git to manage their code base. Such tools provide their own methods of creating diffs or patching software. The following example shows how to create a patch from the original source code using diff , and how to apply the patch using patch.

Patching is used in a later section when creating an RPM; see Section 3. This procedure shows how to create a patch from the original source code for cello. The -p option is used to preserve mode, ownership, and timestamps. Using the Naur options with the diff command is recommended because it fits the majority of usual use cases. However, in this particular case, only the -u option is necessary.

Particular options ensure the following:. For more information on common arguments for the diff utility, see the diff manual page. The original cello.

For more information, see Section 3. The following procedure shows how to patch cello. Redirect the patch file to the patch command:. Check that the contents of cello.

In the context of this documentation, an Arbitrary Artifact is anything installed from an RPM to the system. This section describes two common ways of placing Arbitrary Artifacts in the system:.

Packagers often use the install command in cases when build automation tooling such as GNU make is not optimal; for example if the packaged program does not need extra overhead. The install command is provided to the system by coreutils , which places the artifact to the specified directory in the file system with a specified set of permissions. The following procedure uses the bello file that was previously created as the arbitrary artifact as a subject to this installation method.

Execute bello from any directory without specifying its full path:. Using the make install command is an automated way to install built software to the system.

In this case, you need to specify how to install the arbitrary artifacts to the system in the Makefile that is usually written by the developer. Add the install section to the Makefile :. Note that the lines under cello: , clean: , and install: must begin with a tab space. Now you can use Makefile not only to build software, but also to install it to the target system. Execute cello from any directory without specifying its full path:. Developers often distribute software as compressed archives of source code, which are then used to create packages.

RPM packagers work with a ready source code archive. This section describes how to put each of the three Hello World programs introduced in Section 2. The implementation only contains the bello shell script, so the resulting tar. This procedure shows how to prepare the bello project for distribution.

For more information about the example source code written in bash, see Section 2. This procedure shows how to prepare the pello project for distribution. For more information about the example source code written in Python, see Section 2. The patch file is not distributed in the archive with the program. This procedure shows how to prepare the cello project for distribution. For more information about the example source code written in C, see Section 2.

An RPM package is a file containing other files and their metadata information about the files that are needed by the system. The rpm package manager uses this metadata to determine dependencies, where to install files, and other information. There are two types of RPM packages. Both types share the file format and tooling, but have different contents and serve different purposes:. Optionally, the patches to source code are included as well.

The following procedures show how to list the utilities provided by the rpmdevtools package. To be able to use the RPM packaging tools, you need to install the rpmdevtools package, which provides several utilities for packaging RPMs. This section describes how to set up a directory layout that is the RPM packaging workspace by using the rpmdev-setuptree utility. The rpmdevtools package must be installed on your system:. This is useful for investigating a failed build if the logs output do not provide enough information.

Here, the packager puts compressed source code archives and patches. The rpmbuild command looks for them here. A SPEC file provides necessary information to the build system by defining instructions in a series of sections. The sections are defined in the Preamble and the Body part.

The Preamble part contains a series of metadata items that are used in the Body part. The Body part represents the main part of the instructions. Table 3. The number of times this version of the software was released.

Reset to 1 when a new Version of the software is built. The full URL for more information about the program. Most often this is the upstream project website for the software being packaged. Path or URL to the compressed archive of the upstream source code unpatched, patches are handled elsewhere. If needed, more SourceX directives can be added, incrementing the number each time, for example: Source1, Source2, Source3, and so on.

The directive can be applied in two ways: with or without numbers at the end of Patch. If no number is given, one is assigned to the entry internally. It is also possible to give the numbers explicitly using Patch0, Patch1, Patch2, Patch3, and so on. If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to BuildArch: noarch.

A comma or whitespace-separated list of packages required for building the program written in a compiled language. A comma- or whitespace-separated list of packages required by the software to run once installed.

If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here. Conflicts are inverse to Requires. If there is a package matching Conflicts , the package cannot be installed independently on whether the Conflict tag is on the package that has already been installed or on a package that is going to be installed. This directive alters the way updates work depending on whether the rpm command is used directly on the command line or the update is performed by an updates or dependency solver.

When used on a command line, RPM removes all packages matching obsoletes of packages being installed. When using an update or dependency resolver, packages containing matching Obsoletes: are added as updates and replace the matching packages.

If Provides is added to a package, the package can be referred to by dependencies other than its name. The following example shows how to obtain the NVR information for a specific package by querying the rpm command. Example 3. Querying rpm to provide the NVR information for the bash package. Here, bash is the package name, 4. Unlike the NVR , the architecture marker is not under direct control of the RPM packager, but is defined by the rpmbuild build environment.

The exception to this is the architecture-independent noarch package. A full description of the software packaged in the RPM. This description can span multiple lines and can be broken into paragraphs. Command or series of commands to prepare the software to be built, for example, unpacking the archive in Source0. This directive can contain a shell script. Command or series of commands for building the software into machine code for compiled languages or byte code for some interpreted languages.

This is only run when creating a package, not when the end-user installs the package. See Section 3. Command or series of commands to test the software.

This normally includes things such as unit tests. A record of changes that have happened to the package between different Version or Release builds. In the context of RPM packaging, buildroot is a chroot environment.

The files in buildroot are later put into a cpio archive, which becomes the main part of the RPM. Starting from 6, the rpmbuild program has its own defaults. An rpm macro is a straight text substitution that can be conditionally assigned based on the optional evaluation of a statement when certain built-in functionality is used.

Hence, RPM can perform text substitutions for you. Every occurrence will be automatically substituted by Version that you defined previously. This section uses the three example implementations of the Hello World!

A program written in a raw interpreted programming language. It demonstrates when the source code does not need to be built, but only needs to be installed.

If a pre-compiled binary needs to be packaged, you can also use this method since the binary would also just be a file. A program written in a byte-compiled interpreted programming language.

It demonstrates byte-compiling the source code and installating the bytecode - the resulting pre-optimized files. A program written in a natively compiled programming language. It demonstrates a common process of compiling the source code into machine code and installing the resulting executables. This utility creates an unpopulated SPEC file, and you fill in the necessary directives and fields. Some programmer-focused text editors pre-populate a new.

The rpmdev-newspec utility provides an editor-agnostic method. The rpmdev-newspec utility does not use guidelines or conventions specific to any particular Linux distribution. The first section includes these directives that rpmdev-newspec grouped together:.

The Name was already specified as an argument to rpmdev-newspec. Set the Version to match the upstream release version of the source code. Increment the initial value whenever updating the package without a change in the upstream release Version - such as when including a patch.

Reset Release to 1 when a new upstream release happens. The Summary is a short, one-line explanation of what this software is. The License field is the Software License associated with the source code from the upstream release. The Source0 field provides URL to the upstream software source code.

It should link directly to the specific version of software that is being packaged. Note that the example URLs given in this documentation include hard-coded values that are possible subject to change in the future. Similarly, the release version can change as well. By using these, you need to update only one field in the SPEC file. BuildRequires specifies build-time dependencies for the package. Requires specifies run-time dependencies for the package.

This is a software written in an interpreted programming language with no natively compiled extensions. Hence, add the BuildArch directive with the noarch value. This tells RPM that this package does not need to be bound to the processor architecture on which it is built. These directives can be thought of as section headings, because they are directives that can define multi-line, multi-instruction, or scripted tasks to occur. This usually involves expansion of compressed archives of the source code, application of patches, and, potentially, parsing of information provided in the source code for use in a later portion of the SPEC file.

Here you can create any directories that will contain the installed files. To create such directories, you can use the RPM macros without having to hardcode the paths. Within this section, you can indicate the role of various files using built-in macros. This is useful for querying the package file manifest metadata using the command[] rpm command. They log packaging changes, not software changes.

This section shows an example SPEC file for the bello program that was written in bash. For more information about bello , see Section 2. An example SPEC file for the bello program written in bash. Name: bello Version: 0. The BuildRequires directive, which specifies build-time dependencies for the package, was deleted because there is no building step for bello.

Bash is a raw interpreted programming language, and the files are just installed to their location on the system. The Requires directive, which specifies run-time dependencies for the package, include only bash , because the bello script requires only the bash shell environment to execute.

For installing bello you only need to create the destination directory and install the executable bash script file there.

RPM macros allow to do this without hardcoding paths. This section shows an example SPEC file for the pello program written in the Python programming language. For more information about pello , see Section 2. Name: pello Version: 0. The pello program is written in a byte-compiled interpreted language. Hence, the shebang is not applicable because the resulting file does not contain the entry.

Because the shebang is not applicable, you may want to apply one of the following approaches:. These approaches are useful especially for large software projects with many thousands of lines of code, where the performance increase of pre-byte-compiled code is sizeable. The BuildRequires directive, which specifies build-time dependencies for the package, includes two packages:.

The Requires directive, which specifies run-time dependencies for the package, includes only the python package. To list these utilities, run:. To set up a directory layout that is the RPM packaging workspace, use the rpmdev-setuptree utility:.

This is useful for investigating a failed build if the logs output do not provide enough information. Here, the packager puts compressed source code archives and patches. The rpmbuild command looks for them here. It tells the build system what to do by defining instructions in a series of sections.

The sections are defined in the Preamble and the Body. The Preamble contains a series of metadata items that are used in the Body. The Body contains the main part of the instructions. The number of times this version of the software was released.

Reset to 1 when a new Version of the software is built. The license of the software being packaged. The full URL for more information about the program. Most often this is the upstream project website for the software being packaged. Path or URL to the compressed archive of the upstream source code unpatched, patches are handled elsewhere.

If needed, more SourceX directives can be added, incrementing the number each time, for example: Source1, Source2, Source3, and so on. The name of the first patch to apply to the source code if necessary. If needed, more PatchX directives can be added, incrementing the number each time, for example: Patch1, Patch2, Patch3, and so on.

If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to BuildArch: noarch. A comma- or whitespace-separated list of packages required for building the program written in a compiled language.

A comma- or whitespace-separated list of packages required by the software to run once installed. If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here. Here, python is the Package Name, 2. Unlike the NVR , the architecture marker is not under direct control of the RPM packager, but is defined by the rpmbuild build environment.

The exception to this is the architecture-independent noarch package. A full description of the software packaged in the RPM. This description can span multiple lines and can be broken into paragraphs. Command or series of commands to prepare the software to be built, for example, unpacking the archive in Source0.

This directive can contain a shell script. Command or series of commands for actually building the software into machine code for compiled languages or byte code for some interpreted languages. This is only run when creating a package, not when the end-user installs the package. Command or series of commands to test the software.

This normally includes things such as unit tests. A record of changes that have happened to the package between different Version or Release builds. The SPEC file can also contain advanced items. For example, a SPEC file can have scriptlets and triggers. In the context of RPM packaging, "buildroot" is a chroot environment. The files in "buildroot" are later put into a cpio archive, which becomes the main part of the RPM.

Starting from Red Hat Enterprise Linux 6 release, the rpmbuild program has its own defaults. As overriding these defaults leads to several problems, Red Hat does not recommend to define your own value of this macro. An rpm macro is a straight text substitution that can be conditionally assigned based on the optional evaluation of a statement when certain built-in functionality is used.

This is useful when, for example, referencing the packaged software Version multiple times in the SPEC file. Every occurrence will be automatically substituted by Version you defined previously.

It signals which distribution is used for the build. In this section we discuss how to create and modify a spec file. To package new software, you need to create a new SPEC file. Instead of writing it manually from scratch, use the rpmdev-newspec utility. It creates an unpopulated SPEC file, and you fill in the necessary directives and fields. For this tutorial, we use the three example implementations of the 'Hello World!

Examine the files. In the following sections, you will populate these SPEC files. The rpmdev-newspec utility does not use guidelines or conventions specific to any particular Linux distribution.

There are three examples below. Each one is fully described, so you can go to a specific one if it matches your packaging needs. Or, read them all to fully explore packaging different kinds of software. A program written in a raw interpreted programming language.

It demonstrates when the source code does not need to be built, but only needs to be installed. If a pre-compiled binary needs to be packaged, you can also use this method since the binary would also just be a file. A program written in a byte-compiled interpreted programming language. It demonstrates byte-compiling the source code and installating the bytecode - the resulting pre-optimized files. A program written in a natively compiled programming language. It demonstrates a common process of compiling the source code into machine code and installing the resulting executables.

The file has these contents:. Populate the Name , Version , Release , and Summary directives:. Increment the initial value whenever updating the package without a change in the upstream release Version - such as when including a patch. Reset Release to 1 when a new upstream release happens, for example, if bello version 0.

The disttag macro is covered in RPM Macros. The License field is the Software License associated with the source code from the upstream release. Follow this format for the License field: Fedora License Guidelines. The Source0 field provides URL to the upstream software source code.

It should link directly to the version of software that is being packaged. BuildRequires specifies build-time dependencies for the package. There is no building step for bello , because bash is a raw interpreted programming language, and the files are simply installed to their location on the system. Just delete this directive. Requires specifies run-time dependencies for the package. The bello script requires only the bash shell environment to execute, so specify bash in this directive.

Since this is software written in an interpreted programming language with no natively compiled extensions, add the BuildArch directive with the noarch value. This tells RPM that this package does not need to be bound to the processor architecture on which it is built. In our example we will use only a short description. This usually involves expansion of compressed archives of the source code, application of patches, and, potentially, parsing of information provided in the source code for use in a later portion of the SPEC.

However, since a bash does not need to be built, simply remove what was provided by the template and leave this section blank. Here we should create any directories that will contain the installed files.

Since for installing bello we only need to create the destination directory and install the executable bash script file there, we will use the install command. RPM macros allow us to do this without hardcoding paths. Within this section, you can indicate the role of various files using built-in macros. This is useful for querying the package file manifest metadata using the rpm command.

They log packaging changes, not software changes. You have now written an entire SPEC file for bello. The full SPEC file for bello now resembles:. Before we start down this path, we need to address something somewhat unique about byte-compiled interpreted software.

Since we will be byte-compiling this program, the shebang is no longer applicable because the resulting file will not contain the entry. This might seem silly for our small example but for large software projects with many thousands of lines of code, the performance increase of pre-byte-compiled code is sizeable.

We will make a small shell script to call our byte compiled code to be the entry point into our software. The Name is already specified because we provided that information to the command line for rpmdev-newspec.

When a new upstream release happens for example, pello version 0. We should note that this example URL has hard coded values in it that are possible to change in the future and are potentially even likely to change such as the release version 0.

We can simplify this by only needing to update one field in the SPEC file and allowing it to be reused. Next up we have BuildRequires and Requires , each of which define something that is required by the package. However, BuildRequires is to tell rpmbuild what is needed by your package at build time and Requires is what is needed by your package at run time. In this example we will need the python package in order to perform the byte-compile build process.

We will also need the python package in order to execute the byte-compiled code at runtime and therefore need to define python as a requirement using the Requires directive. We will also need the bash package in order to execute the small entry-point script we will use here. Something we need to add here since this is software written in an interpreted programming language with no natively compiled extensions is a BuildArch entry that is set to noarch in order to tell RPM that this package does not need to be bound to the processor architecture that it is built using.

We will walk through them one by one just as we did with the previous items. Most often what happens here is the expansion of compressed archives of the source code, application of patches, and potentially parsing of information provided in the source code that is necessary in a later portion of the SPEC. Here we will perform a byte-compilation of our software.

For those who read the Preparing Software for Packaging section, this portion of the example should look familiar. However, our RPM Macros help us accomplish this task without having to hardcode paths. We had previously discussed that since we will lose the context of a file with the shebang line in it when we byte compile that we will need to create a simple wrapper script in order to accomplish that task.

The reason for showing the example option that we are is simply to demonstrate that the SPEC file itself is scriptable. We will also need to actually install the byte-compiled file into a library directory on the system such that it can be accessed.

Also, within this section you will sometimes need a built-in macro to provide context on a file. This can be useful for Systems Administrators and end users who might want to query the system with rpm about the resulting package. This is not meant to be a log of what changed in the software from release to release, but specifically to packaging changes.

Each change entry can contain multiple items and each item should start on a new line and begin with a - character. Below is our example entry:. From there we have a - character before the Version-Release, which is an often used convention but not a requirement. Then finally the Version-Release.

In the next section we will cover how to build the RPM! When a new upstream release happens for example, cello version 2. However, we will add one to this grouping as it is closely related to the Source0 and that is our Patch0 which will list the first patch we need against our software.

We should note that this example URL has hard coded values in it that are possible to change in the future and are potentially even likely to change such as the release version 1. The next item is to provide a listing for the. We will need a listing of Patch0: cello-output-first-patch. In this example we will need the gcc and make packages in order to perform the compilation build process.

Runtime requirements are fortunately handled for us by rpmbuild because this program does not require anything outside of the core C standard libraries and we therefore will not need to define anything by hand as a Requires and can omit that directive.

Since wrote a simple Makefile for our C implementation, we can simply use the GNU make command provided by rpmdev-newspec. RPMs are built with the rpmbuild command. Different scenarios and desired outcomes require different combinations of arguments to rpmbuild. This section describes the two prime scenarios:.

The rpmbuild command expects a certain directory and file structure. This is the same structure as set up by the rpmdev-setuptree utility. The previous instructions also confirmed to the required structure. This includes the exact SPEC file, the source code, and all relevant patches. This is useful for looking back in history and for debugging. To be able to build a binary RPM on a different hardware platform or architecture.

The -bs option stands for "build source". Building it from a SPEC file using the rpmbuild -bb command. The -bb option stands for "build binary". The output generated when creating a binary RPM is verbose, which is helpful for debugging. The output varies for different examples and corresponds to their SPEC files. For this tutorial, execute the rpm -Uvh commands above to continue interacting with the SPEC files and sources.

To build bello , pello , and cello from their SPEC files, run:. After creating a package, it is good to check its quality. Quality of the package, not of the software delivered within it. The main tool for this is rpmlint. Note that rpmlint has very strict guidelines, and sometimes it is acceptable and necessary to skip some of its Errors and Warnings, as shown in the following examples. For bello. It says that the URL listed in the Source0 directive is unreachable. This is expected, because the specified example.

Presuming that we expect this URL to work in the future, we can ignore this warning. Assuming the link will be working in the future, we can ignore this warning. The no-documentation and no-manual-page-for-binary warnings say that the RPM has no documentation or manual pages, because we did not provide any. There are many errors, because we intentionally wrote this SPEC file to be uncomplicated and to show what errors rpmlint can report.

For the sake of this example, we ignore these errors, but for packages going in production you need a good reason for ignoring this error. Assuming that we expect the URL to become valid in the future, we can ignore this error. Filesystem Hierarchy Standard. This directory is normally reserved for shared object files, which are binary files. This is an example of an rpmlint check for compliance with Filesystem Hierarchy Standard.

Normally, use RPM macros to ensure the correct placement of files. For the sake of this example, we can ignore this warning. Since this file contains the shebang , rpmlint expects the file to be executable. For the purpose of the example, leave this file without execute permissions and ignore this error. The only warning for cello. Our RPMs are now ready and checked with rpmlint.

This concludes the tutorial. This chapter covers topics that are beyond the scope of the introductory tutorial but are often useful in real-world RPM packaging.

Signing a package is a way to secure the package for an end user. Secure transport can be achieved with implementation of the HTTPS protocol, which can be done when the package is downloaded just before installing. However, the packages are often downloaded in advance and stored in local repositories before they are used. The packages are signed to make sure no third party can alter the content of a package. Adding a signature to an already existing package. Replacing the signature on an already existing package.

In most cases packages are built without a signature. The signature is added just before the release of the package. In order to add another signature to the package package, use the --addsign option.

With two signatures, the package makes its way to a retailer. The retailer checks the signatures and, if they check out, adds their signature as well. The package now makes its way to a company that wishes to deploy the package. After checking every signature on the package, they know that it is an authentic copy, unchanged since it was first created. The two pgp strings in the output of the rpm --checksig command show that the package has been signed twice.

RPM makes it possible to add the same signature multiple times. The --addsign option does not check for multiple identical signatures. This is possible because the Makefile for the cello program is available. RPMs are built with the rpmbuild command. This command expects a certain directory and file structure, which is the same as the structure that was set up by the rpmdev-setuptree utility. Different use cases and desired outcomes require different combinations of arguments to the rpmbuild command.

The two main use cases are:. Run the rpmbuild command with the specified SPEC file:. The -bs option stands for the build source. The following example shows building source RPMs for the bello , pello , and cello projects. To rebuild bello , pello , and cello from their SRPMs, run:. The output generated when creating a binary RPM is verbose, which is helpful for debugging.

The output varies for different examples and corresponds to their SPEC files. Run the rpmbuild command with the bb option:. To do so, use the following procedure. Run the rpmbuild command with one of the below options and with the source package specified:. After creating a package, it is necessary to check the quality of the package. The main tool for checking package quality is rpmlint. Note that rpmlint has very strict guidelines; hence it is sometimes acceptable to skip some of its errors and warnings, as shown in the following examples.

In the examples described in the following sections, rpmlint is run without any options, which produces a non-verbose output. For detailed explanations of each error or warning, you can run rpmlint -i instead.

Output of running the rpmlint command on the SPEC file for bello. For bello. This is expected, because the specified example. Presuming that we expect this URL to work in the future, we can ignore this warning. Output of running the rpmlint command on the SRPM for bello. Assuming the link will be working in the future, we can ignore this warning. When checking binary RPMs, rpmlint checks for the following items:. Output of running the rpmlint command on the binary RPM for bello. The no-documentation and no-manual-page-for-binary warnings say that he RPM has no documentation or manual pages, because we did not provide any.

Apart from the above warnings, the RPM passed rpmlint checks. Output of running the rpmlint command on the SPEC file for pello. Presuming that this URL will work in the future, you can ignore this warning.

For the sake of this example, you can safely ignore these errors. However, for packages going into production make sure to check all errors carefully. Output of running the rpmlint command on the SRPM for pello. Assuming that the URL will be valid in the future, you can safely ignore this error. Output of running the rpmlint command on the binary RPM for pello. The no-documentation and no-manual-page-for-binary warnings say that the RPM has no documentation or manual pages, because you did not provide any.

This directory is normally reserved for shared object files, which are binary files. This is an example of an rpmlint check for compliance with Filesystem Hierarchy Standard. Normally, use RPM macros to ensure the correct placement of files. For the sake of this example, you can safely ignore this warning.

The rpmlint tool expects the file to be executable, because the file contains the shebang. For the purpose of this example, you can leave this file without execute permissions and ignore this error. Apart from the above warnings and errors, the RPM passed rpmlint checks. Output of running the rpmlint command on the SPEC file for cello. For cello. Output of running the rpmlint command on the SRPM for cello.

Assuming the link will be working in the future, you can ignore this warning. Output of running the rpmlint command on the binary RPM for cello. The no-documentation and no-manual-page-for-binary warnings say that he RPM has no documentation or manual pages, because you did not provide any.

To enable the logging of RPM transactions to syslog, make sure that the syslog plug-in is installed on the system:. However, you can configure syslog to use another location to store the messages. In particular cases, for example, if a package required by RPM is damaged, it is necessary to extract the content of the package. In such cases, if an RPM installation is still working despite the damage, you can use the rpm2archive utility to convert an.

If the RPM installation is severely damaged, you can use the rpm2cpio utility to convert the RPM package file to a cpio archive. The following procedure describes how to convert an rpm payload to a tar archive using the rpm2archive utility.

Replace filename with the name of the. The resulting file has the. For example, to archive the bash package:. Chapter 3. Packaging software. Files RPM header package metadata The rpm package manager uses this metadata to determine dependencies, where to install files, and other information.

Prerequisites You installed the rpmdevtools package, which provides several utilities for packaging RPMs: yum install rpmdevtools. Version The upstream version number of the software. Release The number of times this version of the software was released. Summary A brief, one-line summary of the package.

License The license of the software being packaged. Source0 Path or URL to the compressed archive of the upstream source code unpatched, patches are handled elsewhere. Patch The name of the first patch to apply to the source code if necessary. The directive can be applied in two ways: with or without numbers at the end of Patch. BuildArch If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to BuildArch: noarch.

BuildRequires A comma or whitespace-separated list of packages required for building the program written in a compiled language. Requires A comma- or whitespace-separated list of packages required by the software to run once installed. ExcludeArch If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here.