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. 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. The package itself does not have to be installed. This will give you possibly multiple hits, as a file can be part of packages from different repositories. If you want to find the related package of a binary or file , we first have to know the full path.
If you know the binary, then use the which command to discover where it is stored. Using the find command is another option, but may be less efficient. With the dpkg package management tool we can find the related package. If you already know the package name, you can quickly look up the files that are installed by a Debian package. Systems running the distributions from SuSE can use the zypper tool to find the link between a file and a package.
Got more useful commands to share? Let it know in the comments and we add them to the article. So you are interested in Linux security?
Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become or stay a Linux security expert.
See training package. Run automated security scans and increase your defenses. This version also works on non redhat based distro's that still use rpm's such as openSUSE — simotek. Each has their own purpose.
Furthermore, yum whatprovides However, rpm -qf Therefore, I propose that the root requirements are functionally equivalent for both methods. Show 2 more comments. The most popular answer is incomplete: Since this search will generally be performed only for files from installed packages, yum whatprovides is made blisteringly fast by disabling all external repos the implicit "installed" repo can't be disabled.
This website is offline! The website does not appear to search for files; only package names with the search term. As the docs says, you can search for executables by their single path name or any file with the absolute path name. Arash Arash 5 5 silver badges 8 8 bronze badges. Using only the rpm utility, this should work in any OS that has rpm: rpm -q --whatprovides [file name] Ref. Tim M. You can do this alike here but with your package. Sign up or log in Sign up using Google.
Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog.
0コメント