Steps to get your system prepped to create RPMs
1)First we need to install all the packages necessary to start building RPM packages (as root):
dnf install @development-tools
dnf install fedora-packager dnf install rpmdevtools
yum install @development-tools
yum install fedora-packager yum install rpmdevtools
2)OPTIONAL: Create a custom user specifically for packaging. Good idea especially for not accidentally leaking your private keys to the world. (as root)
/usr/sbin/useradd makerpm usermod -a -G mock makerpm passwd makerpm
3) Setup your directory structure for the build environment. Do this on the makerpm user if you created one.
Use the following workflow for creating your RPM
1)Get source and save it to ~/rpmbuild/SOURCES
2) Open a terminal in ~/rpmbuild/SPECS and run the following command
3) Edit and add in the necessary data into the SPEC
4) In a terminal goto your SPEC folder if you left it and run the following command. Install missing packages if need be and rerun the command if necessary.
rpmbuild -ba SPECFILE.spec
5) Once you have an SRPM in ~/rpmbuild/SRPMS you can turn around and test it out completely with mock. If you cannot run this as your build user add it to the mock user group.
mock -r MOCK_PROFILE ~/rpmbuild/SRPMS/PACKAGENAME.srpm
Mock will create a fake build chroot and start chugging away at installing dependencies and then fire off the build. If it fails, fix what is broken in the SPEC and rebuild the SRPM and then rerun mock. A package built on EL should build on Fedora but this is not guaranteed without some edits, and vice-versa. Easiest method if you are building for both is to have two separate user accounts with separate SPEC files.
Working with the SPEC file
First off for completeness, create your spec using rpmdev-newspec. This will ensure that all the necessary sections are defined and all the macros to facilitate a proper SPEC are present. You won’t always need all them, but its simpler to delete what isn’t needed rather than fidget for hours before you realize what you missed.
Fill in the package name here.
Fill in the version information here
This is the iterative release. If you are making a small change, increment this. Don’t blow this off, as if you release two packages that are the same iteration, the new changes will not be pushed in the repo to users with the original. So if your first release is 1.0.0-1 and you found a glitch in your rpm that was published to the repo, fix it, and iterate it as 1.0.0-2.
A summary of what this software does.
Fill in what license the code is under. Can be found in the source download or on the github page.
The link to the page where the software was obtained
You can have a seriers of these but need at least one. All source code files need to be listed here. You can include compressed archives. If you have external files such as icons, .desktop files, or premade configurations, list each as Source1, Source2, etc.
The required packages for building the package go here. One package per line, with successive ones also having the BuildRequires: leadin.
Same as BuildRequires: but instead of building, this is for running the program(s) compiled from the source. Again, one entry per line, and successive entries also require the Requires: leadin
This is the description of the package as you would see it in the repo query (such as yum info gedit). Personally I prefer to copy and paste from the website since they are better marketers and descriptors than what I can come up with
he %prep script is the first script RPM executes during a build. Prior to the %prep script, RPM has performed preliminary consistency checks, such as whether the spec file’s source tag points to files that actually exist. Just prior to passing control over to the %prep script’s contents, RPM changes directory into RPM’s build area, which, by default, is ~/rpmbuild/BUILD.
The %setup macro, which is used to unpack the original sources.
The %build script picks up where the %prep script left off. Once the %prep script has gotten everything ready for the build, the %build script is usually somewhat anti-climactic — normally invoking make, maybe a configuration script, and little else.
Like %prep before it, the %build script has the same assortment of environment variables to draw on. Also, like %prep, %build changes directory into the software’s top-level build directory (located in RPM_BUILD_DIR, or usually called <name>–<version>).
Unlike %prep, there are no macros available for use in the %build script. The reason is simple: Either the commands required to build the software are simple (such as a single make command), or they are so unique that a macro wouldn’t make it easier to write the script.
Optional macro for automating the usual ./configure. This is not always the case, and you should consult the documentation in the source or on their website for how one actually builds the source.
The actual build command. This presumes that you are able to build with a simple make. This is not always the case, and you should consult the documentation in the source or on their website for how one actually builds the source.
Macro for setting up the installation of your application in the fake build environment
rm -rf $RPM_BUILD_ROOT
Leave this alone. This cleans up for the following macro %make_install.
The macro for installing the software. This is going to assume that the usual ./configure && make && make install is the correct build steps. This is not always the case, and you should consult the documentation in the source or on their website for how one actually builds the source.
This is where all the files of the finished package are declared. A simple cheat is to leave this blank and copy over the files that are complained about in the rpmbuild -ba specfile command’s error output.
This is where you declare the documentation
A changelog from version to version. Helps to keep track of what happened when and by whom.
The vital reads :
Some extras that may be of use: