Rpm patch options

Controlling the Build. After describing information about the package, the crucial step comes when you need to build the package. The spec file should contain all the commands needed to build the application or library you want to package. But, and this is the important part, most of the build process should be run from a Makefile or other conventional way to build applications. Using a build tool such as make means that you can test the application outside of the RPM system.

Instead, you use the RPM to package the application. The next sections cover how to control the build run by rpmbuild by defining commands within your spec files. You can contribute to this guide by submitting an issue or a pull request on the GitHub repository. Feel free to file an issue ticket with feedback, submit a pull request on GitHub , or both! Many software vendors distribute their software via a conventional archive file such as a tarball.

However, there are several advantages in packaging software into RPM packages. These advantages are outlined below. Users can use standard package management tools for example Yum or PackageKit to install, reinstall, remove, upgrade and verify your RPM packages.

Because RPM maintains a database of installed packages and their files, users can easily query and verify packages on their system.

RPM allows you to take pristine software sources and package them into source and binary packages for your users. In source packages, you have the pristine sources along with any patches that were used, plus complete build instructions. This design eases the maintenance of the packages as new versions of your software are released.

You can add your package to a Yum repository that enables clients to easily find and deploy your software. Using a GPG signing key, you can digitally sign your package so that users are able to verify the authenticity of the package.

Creating an RPM package can be complicated. Here is a complete, working RPM Spec file with several things skipped and simplified. The command rpmdev-setuptree creates several working directories. The command rpmbuild creates the actual rpm package. The output of this command can be similar to:. It can be installed in the system and tested.

This chapter is about source code and creating software, which are a necessary background for an RPM Packager. Source code is human-readable instructions to the computer, which describe how to perform a computation. Source code is expressed using a programming language. This tutorial features three versions of the Hello World program, each written in a different programming language.

Programs written in these three different languages are packaged differently, and cover three major use cases of an RPM packager. Hello World written in C :. The purpose of every one of the three programs is to output Hello World on the command line.

There are many methods by which human-readable source code becomes machine code - instructions the computer follows to actually execute the program. However, all methods can be reduced to these three:. Natively compiled software is software written in a programming language that compiles to machine code, with a resulting binary executable file.

Such software can be run stand-alone. RPM packages built this way are architecture -specific. The resulting package will have architecture specified in its name. Some programming languages, such as bash or Python , do not compile to machine code. Instead, their programs' source code is executed step by step, without prior transformations, by a Language Interpreter or a Language Virtual Machine.

Software written entirely in interpreted programming languages is not architecture -specific. Hence, the resulting RPM Package will have string noarch in its name. Interpreted languages are either byte-compiled or raw-interpreted. These two types differ in program build process and in packaging procedure. Raw-interpreted language programs do not need to be compiled at all, they are directly executed by the interpreter. Byte-compiled languages need to be compiled into byte code, which is then executed by the language virtual machine.

For software written in compiled languages, the source code goes through a build process, producing machine code. This process, commonly called compiling or translating , varies for different languages. The resulting built software can be run or " executed ", which makes computer perform the task specified by the programmer. For software written in raw interpreted languages, the source code is not built, but executed directly.

For software written in byte-compiled interpreted languages, the source code is compiled into byte code, which is then executed by the language virtual machine. In this example, you will build the cello.

Instead of building the source code manually, you can automate the building. This is a common practice used by large-scale software. Automating building is done by creating a Makefile and then running the GNU make utility. To set up automated building, create a file named Makefile in the same directory as cello. Since there is already a build present, make clean it and run make again:. The next two examples showcase byte-compiling a program written in Python and raw-interpreting a program written in bash.

In the two examples below, the! The shebang enables using a text file as an executable: the system program loader parses the line containing the shebang to get a path to the binary executable, which is then used as the programming language interpreter. In this example, you will 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. Procedure for byte-compiling programs is different for different languages. In this example, you will raw-interpret the bello program written in the bash shell built-in language.

Programs written in shell scripting languages, like bash , are raw-interpreted. Hence, you only need to make the file with source code executable and run it:. A patch is source code that updates other source code. It is formatted as a diff , because it represents what is different between two versions of text.

A diff is created using the diff utility, which is then applied to the source code using the patch utility. In the following example, we create a patch from the original source code using diff and then apply it using patch. How is patching related to RPM packaging? In packaging, instead of simply modifying the original source code, we keep it, and use patches on it. We retain the original cello. To patch cello. It specifies in which directory which files should be located.

For example, an executable file should go into a directory that is in the system PATH variable. We will explore two popular ways of placing Arbitrary Artifacts in the system: using the install command and using the make install command. Sometimes using build automation tooling such as GNU make is not optimal - for example, if the packaged program is simple and does not need extra overhead.

In these cases, packagers often use the install command provided to the system by coreutils , which places the artifact to the specified directory in the filesystem with a specified set of permissions.

The example below is going to use the bello file that we had previously created as the arbitrary artifact subject to our installation method.

Note that you will either need sudo permissions or run this command as root excluding the sudo portion of the command. Therefore, you can execute bello from any directory without specifying its full path:. A popular automated way to install built software to the system is to use the make install command. It requires you to specify how to install the arbitrary artifacts to the system in the Makefile. Now you can use Makefile not only to build software, but also to install it to the target system.

Therefore, you can 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. In this section, you will create such compressed archives. Software should be distributed with a software license.

For the examples, we will use the GPLv3 license. An RPM packager needs to deal with license files when packaging. In the examples below, we put each of the three Hello World programs into a gzip -compressed tarball.

Software is often released this way to be later packaged for distribution. The bello project implements Hello World in bash. The implementation only contains the bello shell script, so the resulting tar. Let us assume that this is version 0. The pello project implements Hello World in Python. The implementation only contains the pello. The cello project implements Hello World in C. The implementation only contains the cello. Let us assume that this is version 1.

Note that the patch file is not distributed in the archive with the program. While these distributions are the target environment, this guide is mostly applicable to all RPM based distributions. However, the instructions need to be adapted for distribution-specific features, such as prerequisite installation items, guidelines, or macros. This tutorial assumes no previous knowledge about packaging software for any Operating System, Linux or otherwise.

This section covers the basics of the RPM packaging format. See Advanced Topics for more advanced information. An RPM package is simply a file containing other files and information about them needed by the system. Specifically, an RPM package consists of the cpio archive, which contains the files, and the RPM header, which contains metadata about the package. The rpm package manager uses this metadata to determine dependencies, where to install files, and other information. A binary RPM contains the binaries built from the sources and patches.

The rpmdevtools package, installed in Prerequisites , provides several utilities for packaging RPMs. 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. As of this writing there are no specific helper macros for performing this, but for example the embedded Lua interpreter can be used for the purpose:.

Patch1: bash Patch2: bash Patch3: bash Patch4: bash Patch bash When i run command "rpm -qa grep redhat-release'. Can i edit some configuration file to update this? This is the name-version-release. It is was defined in the. How to upgrade rpm package? For example, packages for RHEL 7 Server Note: An active product subscription that includes entitlements to the package are required to view or download packages.

Installing or Upgrading There are two main options of rpm command that are used to install or upgrade RPM packages: -i is used to install a new package. This installs a new package. This install the package or upgrades the package currently installed to a newer version. This is the same as install, except all other version s of the package are removed after the new package is installed.

Examples: Note: These examples assume the packages are in a directory on your system. To install an RPM package, we use of the -i flag. As mentioned before, you use this flag when you are installing a kernel RPM. In this case, you will want to leave your old kernel in place, at least temporarily, in case the new kernel does not boot. In this example, we first check to see the names of the new RPM packages with the ls command. Then we query the RPM database to see which kernel packages are already installed.

Note the -v option will show verbose output and the -h will show the hash marks, which represents action of the progress of the RPM upgrade. Lastly, we run another RPM query to verify the package will be available.

EL kernel