Build rpm from source files

Most of the sources listed in the 'Repositories' wiki page have such resources and features, but some do not. For example, it is almost certain that you will have success in rebuilding Red Hat or CentOS packages for the same major version.

Some SRPMs up to Fedora 11 may rebuild on CentOS-5 without problems but those from Fedora 11 and later currently require use of the "--nomd5" flag with the rpm command to install. Finally, some distribution-independent open source software is available in the form of SRPMs. You may be able use these instructions to rebuild those SRPMs on your system. When rebuilding SRPMs, you will probably have more chance of success for packages that are add-ons to the system, rather than for core packages.

If dependencies for an SRPM you are trying to rebuild require updating core packages it is probably time to look for an older SRPM as a starting point. You should probably not try to use this procedure to upgrade glibc, gcc, python, perl, or other core system components to a later version. If you do that, you risk damaging your system in a way that may be hard to recover from.

You may save the file to any directory. Note: Although you may have success with rebuilding and using SRPMs from other distros, it is not guaranteed that you will. You should be aware that you may even damage your system in a way that is hard to recover by installing rebuilt RPMs from other distros. You will see the same information populated from your skeleton file we created earlier.

The following information describes the items in more detail. Next, create the RPM package with your new spec file.

Note that the -ba stands for "Build binary and source packages". These additional options will pause the rpmbuild process at certain points to help with troubleshooting. For our case, we will just build the RPM package. Now, install the RPM package. Since we aren't dealing with dependencies for this package, no need to check.

If any errors are output during the rpmbuild command, make sure to read the output for the specific issue that's occurring. Please note that this article is published by Xmodulo. 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. We did not cover building from source code, but if you are a developer, that should be a simple step from this point.

Creating rpm packages is another good way to be a lazy sysadmin and save time and effort. It provides an easy method for distributing and installing the scripts and other files that we as sysadmins need to install on many hosts. Edward C. Baily, Maximum RPM , updated online version.

RPM Documentation : This web page lists most of the available online documentation for rpm. It includes many links to other websites and information about rpm. It's an interesting guide however as someone with some experience in rpm packages I still have some hints for you. This allows a reproducabiliy on a different machine under a different user. People don't like when packages mess with their system. Thanks for these tips.

I appreciate them. One thing about writing for Opensource. I will definitely try out hint 1. So adding the link in cron. I also recommend taking a look at "fpm" which can be a much lighter-weight way of creating RPM packages without having to set up build trees, mess around with. For example, if all you want to do is turn a directory tree into an RPM package then fpm can do this with one command like "fpm -s dir -t rpm [..

Although I do agree with you, OpenBuildService does make this easier, it's also good to know what's happening behind the scenes. Very good article, thank you for this. When each script get's run, they get passed how many instances of the package are installed.

How does that help? It allows you to do if statements to determine if a script should be run or not. I just put my testrpm spec files up on github if you want a better set of examples on when scripts run. I've been using these for many years whenever I'm unclear on which script is run and when. Note: I am working on relocatable directory and the rpm i am using, does not support relocatable directory.