Here is the content of the spec-file we recently created. If unsure about what a macro translates to which can be kind of confusing I recommend using the rpm —eval command like shown below:. The scope of this article is not to describe every kind of macro, but the three kinds are the most uselful:.
Okey, enough with the theory phu. Just follow along on the command-line:. A spec file is basically a set of instructions on how to build the rpm package. The Summary tag is a short description of the package. The Name, Version, and Release tags are used to create the name of the rpm file, as in utils Incrementing the release and version numbers lets you create rpms that can be used to update older ones.
The License tag defines the license under which the package is released. I always use a variation of the GPL. Specifying the license is important to clarify the fact that the software contained in the package is open source.
This is also why I included the license and GPL statement in the files that will be installed. The URL is usually the web page of the project or project owner. In this case, it is my personal web page.
The Group tag is interesting and is usually used for GUI applications. The value of the Group tag determines which group of icons in the applications menu will contain the icon for the executable in this package.
Used in conjunction with the Icon tag which we are not using here , the Group tag allows adding the icon and the required information to launch a program into the applications menu structure. The Packager tag is used to specify the person or organization responsible for maintaining and creating the package.
The Requires statements define the dependencies for this rpm. Each is a package name. If DNF cannot find one or more of the required packages, it will throw an error indicating which packages are missing and terminate. The BuildRoot line specifies the top-level directory in which the rpmbuild tool will find the spec file and in which it will create temporary directories while it builds the package.
The finished package will be stored in the noarch subdirectory that we specified earlier. The comment showing the command syntax used to build this package includes the option —target noarch , which defines the target architecture.
Because these are Bash scripts, they are not associated with a specific CPU architecture. If this option were omitted, the build would be targeted to the architecture of the CPU on which the build is being performed. The rpmbuild program can target many different architectures, and using the --target option allows us to build architecture-specific packages on a host with a different architecture from the one on which the build is performed.
It can be very short or can contain many lines of information. This script is not executed during the installation of the package. This script is just a Bash shell script.
It prepares the build directory, creating directories used for the build as required and copying the appropriate files into their respective directories.
This would include the sources required for a complete compile as part of the build. In the case of our package, we have no pre-compile sources as all of our programs are Bash scripts. So we simply copy those scripts and other files into the directories where they belong in the installed system. This section of the spec file defines the files to be installed and their locations in the directory tree. It also specifies the file attributes and the owner and group owner for each file to be installed.
The file permissions and ownerships are optional, but I recommend that they be explicitly set to eliminate any chance for those attributes to be incorrect or ambiguous when installed. Directories are created as required during the installation if they do not already exist. This would be the place to put any scripts that are required to run during installation of the rpm but prior to the installation of the files.
This section of the spec file is another Bash script. This one runs after the installation of files. This section can be pretty much anything you need or want it to be, including creating files, running system commands, and restarting services to reinitialize them after making configuration changes.
This section contains a script that would be run after the rpm package is uninstalled. This script usually consists of cleanup tasks that simply erasing the files previously installed by the rpm cannot accomplish. This Bash script performs cleanup after the rpm build process. In many cases, additional cleanup may also be required. This optional text section contains a list of changes to the rpm and files it contains. The newest changes are recorded at the top of this section.
I find it easiest to create a link to the actual spec file in that directory so that it can be edited in the development directory and there is no need to copy it to the SPECS directory. Run the following command to build the rpm. It should only take a moment to create the rpm if no errors occur. As root, install the rpm to verify that it installs correctly and that the files are installed in the correct directories. The exact name of the rpm will depend upon the values you used for the tags in the Preamble section, but if you used the ones in the sample, the rpm name will be as shown in the sample command below:.
Use the rpm -q --changelog utils command to view the changelog. View the files installed by the package using the rpm -ql utils command that is a lowercase L in ql. Now you will change the spec file to require a package that does not exist.
This will simulate a dependency that cannot be met. Add the following line immediately under the existing Requires line:. We used the rpm command to install and delete the utils package.
Try installing the package with yum or DNF. You must be in the same directory as the package or specify the full path to the package for this to work.
There are many tags and a couple sections that we did not cover in this look at the basics of creating an rpm package. The resources listed below can provide more information. Building rpm packages is not difficult; you just need the right information. I hope this helps you—it took me months to figure things out on my own. Save my name, email, and website in this browser for the next time I comment. Notify me of followup comments via e-mail.
All rights reserved Terms of Service. Sometimes you might have access to an open source application source code but might not have the RPM file to install it on your system.
The RPM performs the following tasks during the build process. Executes the commands and macros mentioned in the prep section of the spec file. Checks the content of the file list Executes the commands and macros in the build section of the spec file. Macros from the file list is also executed at this step. Creates the binary package file Creates the source package file Once the RPM executes the above steps, it creates the binary package file and source package file.
PJ February 5, , am. Jalal Hajigholamali February 5, , am. Hi, Really very nice article Thanks a lot.. Kert February 5, , pm. Balkrishna March 5, , am. Nice Tutorial,thanks………. Satan November 18, , am. Alan February 18, , am. Gustavo June 9, , am. BoShake October 25, , pm. I encountered this problem.
0コメント