Change to the buildroot and run vim with the name of the spec file you want to create:. Open the spec file in a text editor. The spec file should be similar to the following example:. The Group and BuildRoot tags are deprecated. Although the Group and BuildRoot tags are included in the spec file templates, RPM in Fedora 18 does not require the presence of these tags in the spec file and ignores them.
Edit the Release tag to set the release value of the package. For the License tag, fill in the appropriate license for the software. In the Source tag, fill in the URL of the source archive for the package:. Summary A brief, one-line summary of the package. License The license of the software being packaged. URL The full URL for more information about the program most often this is the upstream project website for the software being packaged.
Source0 Path or URL to the compressed archive of the upstream source code unpatched, patches are handled elsewhere. This is ideally a listing of the upstream URL resting place and not just a local copy of the source. If needed, more SourceX directives can be added, incrementing the number each time such as: Source1, Source2, Source3, and so on. Patch0 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 such as: Patch1, Patch2, Patch3, and so on.
BuildArch If the package is not architecture dependent, i. BuildRequires A comma or whitespace separated list of packages required for building compiling the program. Requires A comma or whitespace separated list of packages required by the software to run once installed.
ExcludeArch In the event a piece of software can not operate on a specific processor architecture, you can exclude it here. Example is to uncompress the archive in Source0.
This can contain shell script. This is normally things such as unit tests. Note One handy utility of the rpm command for packagers is the --eval flag which allows you to ask rpm to evaluate a macro. On a RHEL 7. Note Some programmer focused text editors will pre-populate a new file with the extension. Name : bello Version : 0. Note The creation of a script to call the byte-compiled code or having a non-byte-compiled entry point into the software is something that upstream software developers most often address before doing a release of their software to the world, however this is not always the case and this exercise is meant to help address what to do in those situations.
Name : pello Version : 0. Note You will notice below that we are hard coding the library path. Name : cello Version : 1. Name : cello Version : 0. Note For each example below we run rpmlint without any options, if you would like detailed explanations of what each Error or Warning means, then you can pass the -i option and run each command as rpmlint -i instead of just rpmlint.
Binary RPMs will land here in subdirectories of Architecture. Compressed source archives and any patches should go here, this is where the rpmbuild command will look for them. 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.
The name of the first patch to apply to the source code if necessary. If the package is not architecture dependent, i. A comma or whitespace separated list of packages required for building compiling the program. A comma or whitespace separated list of packages required by the software to run once installed. In the event a piece of software can not operate on a specific processor architecture, you can exclude it here. A full description of the software packaged in the RPM, this can consume multiple lines and be broken into paragraphs.
Command or series of commands to prepare the software to be built. Command or series of commands used to actually perform the build procedure compile of the software.
Command or series of commands used to actually install the various artifacts into a resulting location in the FHS. The list of files that will be installed in their final resting place in the context of the target system. A record of changes that have happened to the package between different Version or Release builds. Handling RPM build errors for unpackaged files 9. Adding Change Log Entries 9. Defining Spec File Macros 9. Built-in macros 9. Spec file-specific macros 9.
Defining new macros 9. Specifying parameters to macros 9. The previous chapter introduces the concepts of how to build RPMs, and briefly covered the spec file, which controls how RPM packages are built and installed.
This chapter delves into how to create spec files and the next chapter covers advanced spec file topics such as using conditional commands and making relocatable packages. A spec file defines all the commands and values that are required for creating a package, everything from the name and version number to the actual commands used to build the program you are packaging.
This chapter covers the spec file syntax and how to write spec files. 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.
To change the public key without having to rebuild each package, use the --resign option. To sign a package at build-time, use the rpmbuild command with the --sign option. This requires entering the PGP passphrase. The "Generating signature" message appears in both the binary and source packaging sections.
The number following the message indicates that the signature added was created using PGP. When using the --sign option for rpmbuild , use only -bb or -ba options for package building. To verify the signature of a package, use the rpm command with --checksig option.
For example:. When building multiple packages, use the following syntax to avoid entering the PGP passphrase multiple times. For example when building the blather and bother packages, sign them by using the following:. Mock is a tool for building packages. It can build packages for different architectures and different Fedora or RHEL versions than the build host has. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.
Mock also offers a multi-package tool, mockchain , that can build chains of packages that depend on each other. See —scm-enable in the documentation. From the upstream documentation. You can build for different distributions or releases just by specifying it on the command line. You simply specify the configuration you want to use minus the. For example, you could build our cello example for both RHEL 7 and Fedora 23 using the following commands without ever having to use different machines.
The build would succeed when you run rpmbuild because foo was needed to build and it was found on the system at build time. However, if you took the SRPM to another system that lacked foo it would fail, causing an unexpected side effect. Mock solves this by first parsing the contents of the SRPM and installing the BuildRequires into its chroot which means that if you were missing the BuildRequires entry, the build would fail because mock would not know to install it and it would therefore not be present in the buildroot.
As you can see, mock is a fairly verbose tool. For more information, please consult the Mock upstream documentation. Something to note is that storing binary files in a VCS is not favorable because it will drastically inflate the size of the source repository as these tools are engineered to handle differentials in files often optimized for text files and this is not something that binary files lend themselves to so normally each whole binary file is stored.
As a side effect of this there are some clever utilities that are popular among upstream Open Source projects that work around this problem by either storing the SPEC file where the source code is in a VCS i. In this section we will cover two different options for using a VCS system, git , for managing the contents that will ultimately be turned into a RPM package.
One is called tito and the other is dist-git. Tito is an utility that assumes all the source code for the software that is going to be packaged is already in a git source control repository. This is good for those practicing a DevOps workflow as it allows for the team writing the software to maintain their normal Branching Workflow. Tito will then allow for the software to be incrementally packaged, built in an automated fashion, and still provide a native installation experience for RPM based systems.
Tito operates based on git tags and will manage tags for you if you elect to allow it, but can optionally operate under whatever tagging scheme you prefer as this functionality is configurable. As we can see here, the spec file is at the root of the git repository and there is a rel-eng directory in the repository which is used by tito for general book keeping, configuration, and various advanced topics like custom tito modules.
We can see in the directory layout that there is a sub-directory entitled packages which will store a file per package that tito manages in the repository as you can have many RPMs in a single git repository and tito will handle that just fine. In this scenario however, we see only a single package listing and it should be noted that it matches the name of our spec file.
All of this is setup by the command tito init when the developers of dist-git first initialized their git repo to be managed by tito. We could then use the output as the installation point for some other component in the pipeline. Below is a simple example of commands that could accomplish this and they could be adapted to other environments. Note that the final command would need to be run with either sudo or root permissions and that much of the output has been omitted for brevity as the dependency list is quite long.
This concludes our simple example of how to use tito but it has many amazing features for traditional Systems Administrators, RPM Packagers, and DevOps Practitioners alike. I would highly recommend consulting the upstream documentation found at the tito GitHub site for more information on how to quickly get started using it for your project as well as various advanced features it offers. The build system is then configured to pull the items that are listed as SourceX entries in the spec files in from this look-aside-cache, while the spec and patches remain in a version control system.
There is also a helper command line tool to assist in this. In an effort to not duplicate documentation, for more information on how to setup a system such as this please refer to the upstream dist-git docs. You can define your own macros. Below is an excerpt from the RPM Official Documentation , which provides a comprehensive reference on macros capabilities. A parameterized macro contains an opts field. The shell output is set with set -x enabled. DhddsG use the --debug option, since rpmbuild deletes temporary files after successful build.
This displays the setup of environment variables, for example:. Only tar -xof is executed instead of tar -xvvof. This option has to be used as first. For example, if the package name is cello , but the source code is archived in hello The -c option can be used if the source code tarball does not contain any subdirectories and after unpacking, files from an archive fill the current directory. The -c option creates the directory and steps into the archive expansion.
An illustrative example:. Essentially, -D option means that following lines are not used:. The -T option disables expansion of the source code tarball by removing the following line from the script:. Option -b which stands for before expands specific sources before entering the working directory. Option -a which stands for after expands those sources after entering. Their arguments are source numbers from the spec file preamble. In this case use -a 1 , as we want to expand Source1 after entering the working directory:.
But if the examples were in the separate cello This identifies the file listed as documentation and it will be installed and labeled as such by RPM. This is often used not only for documentation about the software being packaged but also code examples and various items that should accompany documentation. In the event code examples are included, care should be taken to remove executable mode from the file.
Identifies that the path is a directory that should be owned by this RPM. This is important so that the RPM file manifest accurately knows what directories to clean up on uninstall. Specifies that the following file is a configuration file and therefore should not be overwritten or replaced on a package install or update if the file has been modified from the original installation checksum.
In the event that there is a change, the file will be created with. Your system has many built-in RPM Macros and the fastest way to view them all is to simply run the rpm --showrc command. Note that this will contain a lot of output so it is often used in combination with a pipe to grep. 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 60 different sets of guidelines along with associated RPM Macro sets for subject matter specific RPM Packaging.
One example of this kind 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. Any changes you make will affect every build on your machine. You can create this directory, including all subdirectories using the rpmdev-setuptree utility. By default, it is set to -jX , where X is a number of cores.
If you alter the number of cores, you can speed up or slow down a build of packages. 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. Scriptlet that is executed just before the package is installed on the target system.
Scriptlet that is executed just after the package is installed on the target system. Scriptlet that is executed just before the package is uninstalled from the target system. Scriptlet that is executed just after the package is uninstalled from the target system.
It 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.
0コメント