A parameterized macro contains an opts field. The opts i. Different distributions will supply different sets of recommended RPM Macros based on the language implementation of the software being packaged or the specific Guidelines of the distribution in question. These are often provided as RPM Packages themselves and can be installed with the distribution package manager, such as yum or dnf.
One primary example of this is the Fedora Packaging Guidelines section pertaining specifically to Application Specific Guidelines which at the time of this writing has over 30 different sets of guidelines along with associated RPM Macro sets for subject matter specific RPM Packaging.
One example of these kinds of RPMs would be for Python version 2. The above output displays the raw RPM Macro definitions, but we are likely more interested in what these will evaluate to which we can do with rpm --eval in order to determine what they do as well as how they may be helpful to us when packaging RPMs.
In this section we will cover the most common of these such as Epoch, Scriptlets, and Triggers. First on the list is Epoch , epoch is a way to define weighted dependencies based on version numbers. This was not covered in the SPEC File section of this guide because it is almost always a bad idea to introduce an Epoch value as it will skew what you would normally otherwise expect RPM to do when comparing versions of packages. For example if a package foobar with Epoch: 1 and Version: 1.
This approach is generally only used when absolutely necessary as a last resort to resolve an upgrade ordering issue which can come up as a side effect of upstream software changing versioning number schemes or versions incorporating alphabetical characters that can not always be compared reliably based on encoding.
In RPM Packages, there are a series of directives that can be used to inflict necessary or desired change on a system during install time of the RPM. These are called scriptlets. At install time we will need to notify systemd that there is a new unit so that the system administrator can run a command similar to systemctl start foo.
Is is also common for RPM Macros to exist for this function. In our previous example we discussed systemd needing to be notified about a new unit file , this is easily handled by the systemd scriptlet macros as we can see from the below example output. More information on this can be found in the Fedora systemd Packaging Guidelines. Another item that provides even more fine grained control over the RPM Transaction as a whole is what is known as triggers.
These are effectively the same thing as a scriptlet but are executed in a very specific order of operations during the RPM install or upgrade transaction allowing for a more fine grained control over the entire process. Some of these will be advanced and extend far beyond the introductory material included in this guide. RPM Packaging Guide latest. Docs » Appendix Edit on GitHub. Patch 0 cello-output-first-patch. Support for file checksums other than MD5 has been added. Dependencies for pkg-config and libtool files are automatically generated by rpmbuild.
Various fixes to tar-build mode: The specfile is extracted with sane permissions RhBug Attempting build on tarball with no spec included no longer causes ugly and bogus files to be created RhBug rpmbuild -bs and similar imply —nodeps automatically RhBug rpmbuild automatically creates the build directory structure if necessary.
Several whitespace-in-filenames fixes RhBug noarch sub-packages are permitted in otherwise arch-dependant packages RhBug:??? SELinux contexts are no longer stored in package headers. The contexts vary wildly between different policies and policy-versions, whereas header data is static in nature. The contexts from headers were never used for anything anyway.
Lots of missing failure checks added all over the codebase. File conflicts on non-elf files are enforced on multilib systems too RhBug Several new and updated translations.
Tag data from headers and extensions are now passed around in a container which knows how the memory was allocated, the data type of tag, supports iteration, type safe access methods, formatting to several styles and much more. Support for 64bit integer types has been added. Signature checking has been mostly decoupled from the transaction set A new abstract keyring API has been added and used by the low level signature checking routines.
Public keys can now live outside the rpm database but the feature is incomplete as of this writing A proper callback has been added to rpmlog infrastructure.
Rpm problem sets have been made opaque, new methods for iterating over the sets and accessing the data have been added. Names of utilities, commands, and things normally found in code are written in monospace font. 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. 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.
0コメント