Raw-interpreted language programs do not need to be compiled at all, they aredirectly executed by the interpreter.

Byte-compiled languages need to be compiled into byte code, which is thenexecuted by the language virtual machine.

#include<stdio.h>int main(void) {    printf("Hello World\n");return0;}

Invoke theCcompiler from the GNUCompiler Collection (GCC) to compile the source code into binary:

Execute the resulting output binarycello.

That is all. You have built and ran natively compiled software from source code.

Instead of building the source code manually, you can automate the building.This is a common practice used by large-scale software. Automating building isdone by creating aMakefile and then running theGNUmake utility.

To set up automated building, create a file namedMakefile in the samedirectory ascello.c:

Makefile

Now to build the software, simply runmake:

Since there is already a build present,make clean it and runmake again:

Again, trying to build after another build would do nothing:

Finally, execute the program:

You have now compiled a program both manually and using a build tool.

In this example, you will compile thepello.py program written in Pythoninto byte code, which is then executed by the Python language virtual machine.Python source code can also be raw-interpreted, but the byte-compiled version isfaster. Hence, RPM Packagers prefer to package the byte-compiled version fordistribution to end users.

pello.py

Procedure for byte-compiling programs is different for different languages. Itdepends on the language, the language’s virtual machine, and the tools andprocesses used with that language.

Byte-compilepello.py:

Execute the byte code inpello.pyc:

In this example, you will raw-interpret thebello program written in thebash shell built-in language.

bello

Programs written in shell scripting languages, likebash, are raw-interpreted.Hence, you only need to make the file with source code executable and run it:

$ sudo install -m 0755 bello /usr/bin/bello

$ cd ~$ belloHello World

cello:        gcc -g -o cello cello.cclean:        rm celloinstall:        mkdir -p $(DESTDIR)/usr/bin        install -m 0755 cello $(DESTDIR)/usr/bin/cello

$ makegcc -g -o cello cello.c$ sudo make installinstall -m 0755 cello /usr/bin/cello

$ cd ~$ celloHello World

$ rpm -ql rpmdevtools | grep bin

$ rpmdev-setuptree$ tree ~/rpmbuild//home/user/rpmbuild/|-- BUILD|-- RPMS|-- SOURCES|-- SPECS`-- SRPMS5 directories, 0 files

This table lists the items used in the Preamble section of the RPM SPEC file:

TheName,Version, andRelease directives comprise the file name ofthe RPM package. RPM Package Maintainers and Systems Administrators often callthese three directivesN-V-R orNVR, because RPM package filenames havetheNAME-VERSION-RELEASE format.

You can get an example of anNAME-VERSION-RELEASE by querying usingrpmfor a specific package:

Here,python is the Package Name,2.7.5 is the Version, and34.el7is the Release. The final marker isx86_64, which signals the architecture.Unlike theNVR, the architecture marker is not under direct control of theRPM packager, but is defined by therpmbuild build environment. Theexception to this is the architecture-independentnoarch package.

This table lists the items used in the Body section of the RPM SPEC file:

The SPEC file can also contain advanced items. For example, a SPEC file can havescriptlets andtriggers. They take effect at different points during theinstallation process on the end user’s system (not the build process).

See theScriptlets and Triggers for advanced topics.

# On a RHEL 7.x machine$ rpm --eval %{?dist}.el7# On a Fedora 23 machine$ rpm --eval %{?dist}.fc23

$ cd ~/rpmbuild/SPECS$ rpmdev-newspec bellobello.spec created; type minimal, rpm version >= 4.11.$ rpmdev-newspec cellocello.spec created; type minimal, rpm version >= 4.11.$ rpmdev-newspec pellopello.spec created; type minimal, rpm version >= 4.11.

The first SPEC file is for thebello bash shell script fromPreparing Software for Packaging.

Ensure that you have:

1. Placedbello source code into~/rpmbuild/SOURCES/. SeeWorking with SPEC files.

2. Created the unpopulated SPEC file~/rpmbuild/SPECS/bello.spec. The filehas these contents:

   Name:           belloVersion:Release:        1%{?dist}Summary:License:URL:Source0:BuildRequires:Requires:%description%prep%setup -q%build%configuremake %{?_smp_mflags}%installrm -rf $RPM_BUILD_ROOT%make_install%files%doc%changelog* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org>-

Now, modify~/rpmbuild/SPECS/bello.spec for creatingbello RPMs:

1. Populate theName,Version,Release, andSummary directives:

   • TheName was already specified as an argument torpmdev-newspec.

   • Set theVersion to match the “upstream” release version of thebellosource code,0.1.

   • TheRelease is automatically set to1%{?dist}, which is initially1. Increment the initial value whenever updating the package without achange in the upstream releaseVersion - such as when including a patch.ResetRelease to1 when a new upstream release happens, for example, ifbello version0.2 is released. Thedisttag macro is covered inRPM Macros.

   • TheSummary is a short, one-line explanation of what this software is.

     After your edits, the first section of the SPEC file shouldresemble:

     Name:           belloVersion:        0.1Release:        1%{?dist}Summary:        Hello World example implemented in bash script

2. Populate theLicense,URL, andSource0 directives:

   • TheLicense field is theSoftware Licenseassociated withthe source code from the upstream release.

     Follow this format for theLicense field:Fedora License Guidelines

     For example, useGPLv3+.

   • TheURL field provides URL to the upstream software page. For example, usehttps://example.com/bello. However, for consistency, utilize the %{name}macro and instead usehttps://example.com/%{name}.

   • TheSource0 field provides URL to the upstream software source code. Itshould link directly to the version of software that is being packaged. In thisexample, we can usehttps://example.com/bello/releases/bello-0.1.tar.gz.Instead, use the %{name} macro. Also, use the %{version} macro to accommodate forchanges in version. The resulting entry ishttps://example.com/%{name}/releases/%{name}-%{version}.tar.gz.

     After your edits, the first section of the SPEC file should resemble:

     Name:           belloVersion:        0.1Release:        1%{?dist}Summary:        Hello World example implemented in bash scriptLicense:        GPLv3+URL:            https://example.com/%{name}Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gz

3. Populate theBuildRequires andRequires directives and include theBuildArch directive:

   • BuildRequires specifies build-time dependencies for the package. There isno building step forbello, because bash is a raw interpreted programminglanguage, and the files are simply installed to their location on the system.Just delete this directive.

   • Requires specifies run-time dependencies for the package. Thebelloscript requires only thebash shell environment to execute, so specifybashin this directive.

   • Since this is software written in an interpreted programming language with nonatively compiled extensions, add theBuildArch directive with thenoarch value. This tells RPM that this package does not need to be bound tothe processor architecture on which it is built.

     After your edits, the first section of the SPEC file should resemble:

     Name:           belloVersion:        0.1Release:        1%{?dist}Summary:        Hello World example implemented in bash scriptLicense:        GPLv3+URL:            https://example.com/%{name}Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gzRequires:       bashBuildArch:      noarch

4. Populate the%description,%prep,%build,%install,%files, and%license directives. These directives can be thought of as“section headings”, because they are directives that can define multi-line,multi-instruction, or scripted tasks to occur.

   • The%description is a longer, fuller description of the software thanSummary, containing one or more paragraphs. In our example we will use onlya short description.

   • The%prep section specifies how to prepare the build environment. Thisusually involves expansion of compressed archives of the source code,application of patches, and, potentially, parsing of information provided in thesource code for use in a later portion of the SPEC. In this section we simplyuse the built-in macro%setup -q.

   • The%build section specifies how to actually build the software we arepackaging. However, since abash does not need to be built, simply removewhat was provided by the template and leave this section blank.

   • The%install section contains instructions forrpmbuild on how toinstall the software, once it has been built, into theBUILDROOT directory.This directory is an emptychrootbasedirectory, which resembles the end user’s root directory. Here we should createany directories that will contain the installed files.

     Since for installingbello we only need to create the destination directoryand install the executablebash script file there, we will use theinstall command. RPM macros allow us to do this without hardcoding paths.

     The%install section should look like the following after your edits:

     %installmkdir -p %{buildroot}/%{_bindir}install -m 0755 %{name} %{buildroot}%{_bindir}/%{name}

   • The%files section specifies the list of files provided by this RPM andtheir full path location on the end user’s system. Therefore, the listing forthebello file we are installing is/usr/bin/bello, or, with RPM Macros,%{_bindir}/%{name}.

     Within this section, you can indicate the role of various files using built-inmacros. This is useful for querying the package file manifest metadata using therpm command. For example, to indicate that the LICENSE file is a softwarelicense file, we use the %license macro.

     After your edits, the%files section looks like this:

     %files%license LICENSE%{_bindir}/%{name}

5. The last section,%changelog, is a list of datestamped entries for eachVersion-Release of the package. They log packaging changes, not softwarechanges. Examples of packaging changes: adding a patch, changing the buildprocedure in%build.

   Follow this format for the first line:

   * Day-of-Week Month Day Year Name Surname <email> - Version-Release

   Follow this format for the actual change entry:

   • Each change entry can contain multiple items - one for each change

   • Each item starts on a new line.

   • Each item begins with a- character.

   An example datestamped entry:

   %changelog* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1- First bello package- Example second item in the changelog for version-release 0.1-1

You have now written an entire SPEC file forbello. The full SPEC file forbello now resembles:

The next section covers how to build the RPM.

Our second SPEC file will be for our example written in thePythonprogramming language that you downloaded (or you created a simulated upstreamrelease in thePreparing Software for Packaging section) and placed itssource code into~/rpmbuild/SOURCES/ earlier. Let’s go ahead and open thefile~/rpmbuild/SPECS/pello.spec and start filling in some fields.

Before we start down this path, we need to address something somewhat uniqueabout byte-compiled interpreted software. Since we will be byte-compiling thisprogram, theshebangis no longer applicable because the resulting file will notcontain the entry. It is common practice to either have a non-byte-compiledshell script that will call the executable or have a small bit of thePython code that isn’t byte-compiled as the “entrypoint” into the program’s execution. This might seem silly for our small examplebut for large software projects with many thousands of lines of code, theperformance increase of pre-byte-compiled code is sizeable.

We will make a small shell script to call our byte compiled code to be the entrypoint into our software. We will do this as a part of our SPEC file itself inorder to demonstrate how you can script actions inside the SPEC file. We willcover the specifics of this in the%install section later.

Let’s go ahead and open the file~/rpmbuild/SPECS/pello.spec and startfilling in some fields.

The following is the output template we were given fromrpmdev-newspec.

Just as with the first example, let’s begin with the first set of directivesthatrpmdev-newspec has grouped together at the top of the file:Name,Version,Release,Summary. TheName is already specified becausewe provided that information to the command line forrpmdev-newspec.

Let’s set theVersion to match what the “upstream” release version of thepello source code is, which we can observe is0.1.1 as set by theexample code we downloaded (or we created in thePreparing Software for Packaging section).

TheRelease is already set to1%{?dist} for us, the numerical valuewhich is initially1 should be incremented every time the package is updatedfor any reason, such as including a new patch to fix an issue, but doesn’t havea new upstream releaseVersion. When a new upstream release happens (forexample, pello version0.1.2 were released) then theRelease numbershould be reset to1. Thedisttag of%{?dist} should look familiarfrom the previous section’s coverage ofRPM Macros.

TheSummary should be a short, one-line explanation of what this softwareis.

After your edits, the first section of the SPEC file should resemble thefollowing:

Now, let’s move on to the second set of directives thatrpmdev-newspec hasgrouped together in our SPEC file:License,URL,Source0.

TheLicense field is theSoftware License associated withthe source code from the upstream release. The exact format for how to label theLicense in your SPEC file will vary depending on which specific RPM basedLinux distribution guidelines you arefollowing, we will use the notation standards in theFedora License Guidelines forthis document and as such this field will contain the textGPLv3+

TheURL field is the upstream software’s website, not the source codedownload link but the actual project, product, or company website where someonewould find more information about this particular piece of software. Since we’rejust using an example, we will call thishttps://example.com/pello. However,we will use the RPM macro variable of%{name} in its place for consistency.

TheSource0 field is where the upstream software’s source code should beable to be downloaded from. This URL should link directly to the specificversion of the source code release that this RPM Package is packaging. Onceagain, since this is an example we will use an example value:https://example.com/pello/releases/pello-0.1.1.tar.gz

We should note that this example URL has hard coded values in it that arepossible to change in the future and are potentially even likely to change suchas the release version0.1.1. We can simplify this by only needing to updateone field in the SPEC file and allowing it to be reused. we will use the valuehttps://example.com/%{name}/releases/%{name}-%{version}.tar.gz instead ofthe hard coded examples string previously listed.

After your edits, the top portion of your spec file should look like thefollowing:

Next up we haveBuildRequires andRequires, each of which definesomething that is required by the package. However,BuildRequires is to tellrpmbuild what is needed by your package atbuild time andRequiresis what is needed by your package atrun time.

In this example we will need thepython package in order to perform thebyte-compile build process. We will also need thepython package in order toexecute the byte-compiled code at runtime and therefore need to definepython as a requirement using theRequires directive. We will also needthebash package in order to execute the small entry-point script we willuse here.

Something we need to add here since this is software written in an interpretedprogramming language with no natively compiled extensions is aBuildArchentry that is set tonoarch in order to tell RPM that this package does notneed to be bound to the processor architecture that it is built using.

After your edits, the top portion of your spec file should look like thefollowing:

The following directives can be thought of as “section headings” because theyare directives that can define multi-line, multi-instruction, or scripted tasksto occur. We will walk through them one by one just as we did with the previousitems.

The%description should be a longer, more full length description of thesoftware being packaged than what is found in theSummary directive. For thesake of our example, this isn’t really going to contain much content but thissection can be a full paragraph or more than one paragraph if desired.

The%prep section is where weprepare our build environment or workspacefor building. Most often what happens here is the expansion of compressedarchives of the source code, application of patches, and potentially parsing ofinformation provided in the source code that is necessary in a later portion ofthe SPEC. In this section we will simply use the provided macro%setup -q.

The%build section is where we tell the system how to actually build thesoftware we are packaging. Here we will perform a byte-compilation of oursoftware. For those who read thePreparing Software for Packagingsection, this portion of the example should look familiar.

The%build section of our SPEC file should look as follows.

The%install section is where we instructrpmbuild how to install ourpreviously built software into theBUILDROOT which is effectively achrootbase directory with nothing in it and we will have toconstruct any paths or directory hierarchies that we will need in order toinstall our software here in their specific locations. However, our RPM Macroshelp us accomplish this task without having to hardcode paths.

We had previously discussed that since we will lose the context of a file with theshebangline in it when we byte compile that we will need to createa simple wrapper script in order to accomplish that task. There are many optionson how to accomplish this including, but not limited to, making a separatescript and using that as a separateSourceX directive and the option we’regoing to show in this example which is to create the file in-line in the SPECfile. The reason for showing the example option that we are is simply todemonstrate that the SPEC file itself is scriptable. What we’re going to do iscreate a small“wrapper script” which will execute thePython byte-compiled code by using ahere document. We will also need to actually install the byte-compiled file into a librarydirectory on the system such that it can be accessed.

The%install section should look like the following after your edits:

The%files section is where we provide the list of files that this RPMprovides and where it’s intended for them to live on the system that the RPM isinstalled upon. Note here that this isn’t relative to the%{buildroot} butthe full path for the files as they are expected to exist on the end systemafter installation. Therefore, the listing for thepello file we areinstalling will be%{_bindir}/pello. We will also need to provide a%dirlisting to define that this package “owns” the library directory we created aswell as all the files we placed in it.

Also, within this section you will sometimes need a built-in macro to providecontext on a file. This can be useful for Systems Administrators and end userswho might want to query the system withrpm about the resulting package. Thebuilt-in macro we will use here is%license which will tellrpmbuildthat this is a software license file in the package file manifest metadata.

The%files section should look like the following after your edits:

The last section,%changelog is a list of date-stamped entries thatcorrelate to a specific Version-Release of the package. This is not meant to bea log of what changed in the software from release to release, but specificallyto packaging changes. For example, if software in a package needed patching orthere was a change needed in the build procedure listed in the%buildsection that information would go here. Each change entry can contain multipleitems and each item should start on a new line and begin with a- character.Below is our example entry:

Note the format above, the date-stamp will begin with a* character,followed by the calendar day of the week, the month, the day of the month, theyear, then the contact information for the RPM Packager. From there we have a- character before the Version-Release, which is an often used conventionbut not a requirement. Then finally the Version-Release.

That’s it! We’ve written an entire SPEC file forpello! In the next sectionwe will cover how to build the RPM!

The full SPEC file should now look like the following:

Our third SPEC file will be for our example written in theCprogramminglanguage that we created a simulated upstream release of previously (or youdownloaded) and placed its source code into~/rpmbuild/SOURCES/ earlier.

Let’s go ahead and open the file~/rpmbuild/SPECS/cello.spec and startfilling in some fields.

The following is the output template we were given fromrpmdev-newspec.

Just as with the previous examples, let’s begin with the first set of directivesthatrpmdev-newspec has grouped together at the top of the file:Name,Version,Release,Summary. TheName is alreadyspecified because we provided that information to the command line forrpmdev-newspec.

Let’s set theVersion to match what the “upstream” release version of thecello source code is, which we can observe is1.0 as set by the examplecode we downloaded (or we created in thePreparing Software for Packagingsection).

TheRelease is already set to1%{?dist} for us, the numerical valuewhich is initially1 should be incremented every time the package is updatedfor any reason, such as including a new patch to fix an issue, but doesn’t havea new upstream releaseVersion. When a new upstream release happens (forexample, cello version2.0 were released) then theRelease number shouldbe reset to1. Thedisttag of%{?dist} should look familiar from theprevious section’s coverage ofRPM Macros.

TheSummary should be a short, one-line explanation of what this softwareis.

After your edits, the first section of the SPEC file should resemble thefollowing:

Now, let’s move on to the second set of directives thatrpmdev-newspec hasgrouped together in our SPEC file:License,URL,Source0. However,we will add one to this grouping as it is closely related to theSource0 andthat is ourPatch0 which will list the first patch we need against oursoftware.

TheLicense field is theSoftware Licenseassociated with the source codefrom the upstream release. The exact format for how to label the License in yourSPEC file will vary depending on which specific RPM basedLinuxdistribution guidelines you are following, we will use the notation standards intheFedora License Guidelinesfor this document and as such this field will contain the textGPLv3+

TheURL field is the upstream software’s website, not the source codedownload link but the actual project, product, or company website where someonewould find more information about this particular piece of software. Since we’rejust using an example, we will call thishttps://example.com/cello. However,we will use the rpm macro variable of%{name} in its place for consistency.

TheSource0 field is where the upstream software’s source code should beable to be downloaded from. This URL should link directly to the specificversion of the source code release that this RPM Package is packaging. Onceagain, since this is an example we will use an example value:https://example.com/cello/releases/cello-1.0.tar.gz

We should note that this example URL has hard coded values in it that arepossible to change in the future and are potentially even likely to change suchas the release version1.0. We can simplify this by only needing to updateone field in the SPEC file and allowing it to be reused. we will use the valuehttps://example.com/%{name}/releases/%{name}-%{version}.tar.gz instead ofthe hard coded examples string previously listed.

The next item is to provide a listing for the.patch file we created earliersuch that we can apply it to the code later in the%prep section. We willneed a listing ofPatch0:         cello-output-first-patch.patch.

After your edits, the top portion of your spec file should look like thefollowing:

Next up we haveBuildRequires andRequires, each of which definesomething that is required by the package. However,BuildRequires is to tellrpmbuild what is needed by your package atbuild time andRequiresis what is needed by your package atrun time.

In this example we will need thegcc andmake packages in order toperform the compilation build process. Runtime requirements are fortunatelyhandled for us byrpmbuild because this program does not require anythingoutside of the coreCstandard libraries and we therefore will not need todefine anything by hand as aRequires and can omit that directive.

After your edits, the top portion of your spec file should look like thefollowing:

The following directives can be thought of as “section headings” because theyare directives that can define multi-line, multi-instruction, or scripted tasksto occur. We will walk through them one by one just as we did with the previousitems.

The%description should be a longer, more full length description of thesoftware being packaged than what is found in theSummary directive. For thesake of our example, this isn’t really going to contain much content but thissection can be a full paragraph or more than one paragraph if desired.

The%prep section is where weprepare our build environment or workspacefor building. Most often what happens here is the expansion of compressedarchives of the source code, application of patches, and potentially parsing ofinformation provided in the source code that is necessary in a later portion ofthe SPEC. In this section we will simply use the provided macro%setup -q.

The%build section is where we tell the system how to actually build thesoftware we are packaging. Since wrote a simpleMakefile for ourCimplementation, we can simply use theGNU make command provided byrpmdev-newspec. However, we need to remove the call to%configurebecause we did not provide aconfigure script. The%build section of our SPEC file should look as follows.

The%install section is where we instructrpmbuild how to install ourpreviously built software into theBUILDROOT which is effectively achrootbase directory with nothing in it and we will have to construct anypaths or directory hierarchies that we will need in order to install oursoftware here in their specific locations. However, our RPM Macros help usaccomplish this task without having to hardcode paths.

Once again, since we have a simpleMakefile the installation step can beaccomplished easily by leaving in place the%make_install macro that wasagain provided for us by therpmdev-newspec command.

The%install section should look like the following after your edits:

The%files section is where we provide the list of files that this RPMprovides and where it’s intended for them to live on the system that the RPM isinstalled upon. Note here that this isn’t relative to the%{buildroot} butthe full path for the files as they are expected to exist on the end systemafter installation. Therefore, the listing for thecello file we areinstalling will be%{_bindir}/cello.

Also, within this section you will sometimes need a built-in macro to providecontext on a file. This can be useful for Systems Administrators and end userswho might want to query the system withrpm about the resulting package.The built-in macro we will use here is%license which will tellrpmbuildthat this is a software license file in the package file manifest metadata.

The%files section should look like the following after your edits:

The last section,%changelog is a list of date-stamped entries thatcorrelate to a specific Version-Release of the package. This is not meant to bea log of what changed in the software from release to release, but specificallyto packaging changes. For example, if software in a package needed patching orthere was a change needed in the build procedure listed in the%buildsection that information would go here. Each change entry can contain multipleitems and each item should start on a new line and begin with a- character.Below is our example entry:

Note the format above, the date-stamp will begin with a* character,followed by the calendar day of the week, the month, the day of the month, theyear, then the contact information for the RPM Packager. From there we havea- character before the Version-Release, which is an often used conventionbut not a requirement. Then finally the Version-Release.

That’s it! We’ve written an entire SPEC file forcello! In the next sectionwe will cover how to build the RPM!

The full SPEC file should now look like the following:

Therpmdevtools package provides a set of SPEC file templates for severalpopular languages in the/etc/rpmdevtools/ directory.

SubstituteSPECFILE with the SPEC file. The-bs option stands for "buildsource".

Here we build SRPMs forbello,pello, andcello:

Note that SRPMs were placed into therpmbuild/SRPMS directory, which is partof the structure expected byrpmbuild.

This is all there is to building a SRPM.

To rebuildbello,pello, andcello from Source RPMs (SRPMs), run:

Now you have built RPMs. A few notes:

• The output generated when creating a binary RPM is verbose, which is helpfulfor debugging. The output varies for different examples and corresponds to theirSPEC files.

• The resulting binary RPMs are in~/rpmbuild/RPMS/YOURARCH whereYOURARCHis yourarchitectureor in~/rpmbuild/RPMS/noarch/, if the package is not architecture-specific.

• Invokingrpmbuild --rebuild involves:

  1. Installing the contents of the SRPM - the SPEC file and the source code - into the~/rpmbuild/ directory.

  2. Building using the installed contents.

  3. Removing the SPEC file and the source code.

  You can retain the SPEC file and the source code after building. For this, youhave two options:

  • When building, use the--recompile option instead of--rebuild.

  • Install the SRPMs using these commands:

  $ rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpmUpdating / installing...   1:bello-0.1-1.el7                  ################################# [100%]$ rpm -Uvh ~/rpmbuild/SRPMS/pello-0.1.1-1.el7.src.rpmUpdating / installing...   1:pello-0.1.1-1.el7                ################################# [100%]$ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpmUpdating / installing...   1:cello-1.0-1.el7                  ################################# [100%]

  For this tutorial, execute therpm -Uvh commands above to continueinteracting with the SPEC files and sources.

To buildbello,pello, andcello from their SPEC files, run:

Now you have built RPMs from SPEC files.

Most of the information inRebuilding from a Source RPM apply here.

$ rpmlint bello.specbello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpmbello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Foundbello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el7.noarch.rpmbello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Foundbello.noarch: W: no-documentationbello.noarch: W: no-manual-page-for-binary bello1 packages and 0 specfiles checked; 0 errors, 3 warnings.

$ rpmlint pello.specpello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pycpello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.1.tar.gz HTTP Error 404: Not Found0 packages and 1 specfiles checked; 5 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.1-1.el7.src.rpmpello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Foundpello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pycpello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.1.tar.gz HTTP Error 404: Not Found1 packages and 0 specfiles checked; 5 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.1-1.el7.noarch.rpmpello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Foundpello.noarch: W: only-non-binary-in-usr-libpello.noarch: W: no-documentationpello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/envpello.noarch: W: no-manual-page-for-binary pello1 packages and 0 specfiles checked; 1 errors, 4 warnings.

$ rpmlint ~/rpmbuild/SPECS/cello.spec/home/admiller/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpmcello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Foundcello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el7.x86_64.rpmcello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Foundcello.x86_64: W: no-documentationcello.x86_64: W: no-manual-page-for-binary cello1 packages and 0 specfiles checked; 0 errors, 3 warnings.

$ rpm --addsign blather-7.9-1.i386.rpm            Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:

$ rpm --checksig blather-7.9-1.i386.rpmblather-7.9-1.i386.rpm: size pgp pgp md5 OK

$ rpm --addsig blather-7.9-1.i386.rpm              Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:$ rpm --addsig blather-7.9-1.i386.rpm              Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:$ rpm --addsig blather-7.9-1.i386.rpm              Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:$ rpm --checksig blather-7.9-1.i386.rpmblather-7.9-1.i386.rpm: size pgp pgp pgp pgp md5 OK

$ rpm --resign blather-7.9-1.i386.rpm            Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:

$ rpm --resign b*.rpm            Enter pass phrase:Pass phrase is good.blather-7.9-1.i386.rpm:bother-3.5-1.i386.rpm:

$ rpmbuild -ba --sign blather-7.9.spec            Enter pass phrase:Pass phrase is good.* Package: blather…Binary Packaging: blather-7.9-1Finding dependencies...…Generating signature: 1002Wrote: /usr/src/redhat/RPMS/i386/blather-7.9-1.i386.rpm…Source Packaging: blather-7.9-1…Generating signature: 1002Wrote: /usr/src/redhat/SRPMS/blather-7.9-1.src.rpm

$ rpm --checksig blather-7.9-1.i386.rpmblather-7.9-1.i386.rpm: size pgp md5 OK

When building multiple packages, use the following syntax to avoid entering thePGP passphrase multiple times. For example when building theblather andbother packages, sign them by using the following:

$ git clone https://github.com/release-engineering/dist-git.gitCloning into 'dist-git'...remote: Counting objects: 425, done.remote: Total 425 (delta 0), reused 0 (delta 0), pack-reused 425Receiving objects: 100% (425/425), 268.76 KiB | 0 bytes/s, done.Resolving deltas: 100% (184/184), done.Checking connectivity... done.$ cd dist-git/$ ls *.specdist-git.spec$ tree rel-eng/rel-eng/├── packages│   └── dist-git└── tito.props1 directory, 2 files

$ tito build --test --srpmBuilding package [dist-git-0.13-1]Wrote: /tmp/tito/dist-git-git-0.efa5ab8.tar.gzWrote: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpm$ tito build --builder=mock --arg mock=epel-7-x86_64 --test --rpmBuilding package [dist-git-0.13-1]Creating rpms for dist-git-git-0.efa5ab8 in mock: epel-7-x86_64Wrote: /tmp/tito/dist-git-git-0.efa5ab8.tar.gzWrote: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpmUsing srpm: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpmInitializing mock...Installing deps in mock...Building RPMs in mock...Wrote:  /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm  /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm$ sudo yum localinstall /tmp/tito/dist-git-*.noarch.rpmLoaded plugins: product-id, search-disabled-repos, subscription-managerExamining /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm: dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarchMarking /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm to be installedExamining /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm: dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarchMarking /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm to be installedResolving Dependencies--> Running transaction check---> Package dist-git.noarch 0:0.13-1.git.0.efa5ab8.el7.centos will be installed

%global <name>[(opts)] <body>

%global githash 0ec4e58%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG

cd '/builddir/build/BUILD'rm -rf 'cello-1.0'/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -STATUS=$?if [ $STATUS -ne 0 ]; then  exit $STATUSficd 'cello-1.0'/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

Option-q limits verbosity of%setup macro. Onlytar -xof isexecuted instead oftar -xvvof. This option has to be used as first.

In some cases, the directory from expanded tarball has a different name thanexpected%{name}-%{version}. This can lead to an error of the%setupmacro. The name of a directory has to be specified by-n directory_nameoption.

For example, if the package name iscello, but the source code is archivedinhello-1.0.tgz and containedhello/ directory, the SPEC file contentneeds to be:

The-c option can be used if the source code tarball does not contain anysubdirectories and after unpacking, files from an archive fill the currentdirectory. The-c option creates the directory and steps into the archiveexpansion. An illustrative example:

The directory is not changed after archive expansion.

-D option disables deleting of source code directory. This option is usefulif%setup macro is used several times. Essentially,-D option means thatfollowing lines are not used:

The-T option disables expansion of the source code tarball by removing thefollowing line from the script:

Options-a and-b expand specific sources.

• Option-b (which stands forbefore) expands specific sources beforeentering the working directory.

• Option-a (which stands forafter) expands those sources after entering.Their arguments are source numbers from the spec file preamble.

For example, let’s say thecello-1.0.tar.gz archive contains emptyexamples directory, and the examples are shipped in separateexamples.tar.gz tarball and they expand into the directory of the same name.In this case use-a 1, as we want to expandSource1 after entering theworking directory:

But if the examples were in the separatecello-1.0-examples.tar.gz tarball,which expands intocello-1.0/examples, use-b 1 options, since theSource1 should be expanded before entering the working directory:

You can also use a combination of all these options.

$ rpm -ql python2-rpm-macros/usr/lib/rpm/macros.d/macros.python2$ rpm --showrc | grep python2-14: __python2  /usr/bin/python2CFLAGS="%{optflags}" %{__python2} %{py_setup} %{?py_setup_args} build --executable="%{__python2} %{py2_shbang_opts}" %{?1}CFLAGS="%{optflags}" %{__python2} %{py_setup} %{?py_setup_args} install -O1 --skip-build --root %{buildroot} %{?1}-14: python2_sitearch   %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")-14: python2_sitelib    %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")-14: python2_version    %(%{__python2} -c "import sys; sys.stdout.write('{0.major}.{0.minor}'.format(sys.version_info))")-14: python2_version_nodots     %(%{__python2} -c "import sys; sys.stdout.write('{0.major}{0.minor}'.format(sys.version_info))")

$ rpm --eval %{__python2}/usr/bin/python2$ rpm --eval %{python2_sitearch}/usr/lib64/python2.7/site-packages$ rpm --eval %{python2_sitelib}/usr/lib/python2.7/site-packages$ rpm --eval %{python2_version}2.7$ rpm --eval %{python2_version_nodots}27

$ rpm --showrc | grep systemd-14: __transaction_systemd_inhibit      %{__plugindir}/systemd_inhibit.so-14: _journalcatalogdir /usr/lib/systemd/catalog-14: _presetdir /usr/lib/systemd/system-preset-14: _unitdir   /usr/lib/systemd/system-14: _userunitdir       /usr/lib/systemd/user/usr/lib/systemd/systemd-binfmt %{?*} >/dev/null 2>&1 || :/usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || :-14: systemd_post-14: systemd_postun-14: systemd_postun_with_restart-14: systemd_preun-14: systemd_requiresRequires(post): systemdRequires(preun): systemdRequires(postun): systemd-14: systemd_user_post  %systemd_post --user --global %{?*}-14: systemd_user_postun        %{nil}-14: systemd_user_postun_with_restart   %{nil}-14: systemd_user_preunsystemd-sysusers %{?*} >/dev/null 2>&1 || :echo %{?*} | systemd-sysusers - >/dev/null 2>&1 || :systemd-tmpfiles --create %{?*} >/dev/null 2>&1 || :$ rpm --eval %{systemd_post}if [ $1 -eq 1 ] ; then        # Initial installation        systemctl preset  >/dev/null 2>&1 || :fi$ rpm --eval %{systemd_postun}systemctl daemon-reload >/dev/null 2>&1 || :$ rpm --eval %{systemd_preun}if [ $1 -eq 0 ] ; then        # Package removal, not upgrade        systemctl --no-reload disable  > /dev/null 2>&1 || :        systemctl stop  > /dev/null 2>&1 || :fi

all-%pretrans...any-%triggerprein (%triggerprein from other packages set off by new install)new-%triggerpreinnew-%pre      for new version of package being installed...           (all new files are installed)new-%post     for new version of package being installedany-%triggerin (%triggerin from other packages set off by new install)new-%triggerinold-%triggerunany-%triggerun (%triggerun from other packages set off by old uninstall)old-%preun    for old version of package being removed...           (all old files are removed)old-%postun   for old version of package being removedold-%triggerpostunany-%triggerpostun (%triggerpostun from other packages set off by old un            install)...all-%posttrans

A scriptlet option,-p, in a SPEC file allows to invoke a specific interpreterinstead of the default-p /bin/sh. An illustrative example is a script,which prints out a message after the installation ofpello.py.

1. Open thepello.spec file.

2. Find the following line:

   install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

   Under this line, insert the following code:

   %post -p /usr/bin/python3print("This is {} code".format("python"))

3. Build your package according to theBuilding RPMS chapter.

4. Install your package:

   # dnf install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.1-1.fc27.noarch.rpm

   The output of this command is the following message after the installation:

   Installing       : pello-0.1.1-1.fc27.noarch                              1/1Running scriptlet: pello-0.1.1-1.fc27.noarch                              1/1This is python code

%if expression...%endif

%if expression...%else...%endif

This conditional handles compatibility between RHEL6 and other operating systemsin terms of support of the AS_FUNCTION_DESCRIBE macro. When the package is buildfor RHEL, the%rhel macro is defined and it is expanded to RHEL version. Ifits value is 6, meaning the package is build for RHEL 6, then the references toAS_FUNCTION_DESCRIBE, which is not supported by RHEL6, are deleted fromautoconfig scripts.

This conditional handles compatibility between Fedora version 17 and newer andRHEL6 in terms of support of the%ruby_sitearch macro. Fedora version 17 andnewer defines%ruby_sitearch by default, but RHEL6 does not support thismacro. The conditional checks whether the operating system is RHEL6. If it is,%ruby_sitearch is defined explicitly. Note that0%{?el6} has the samemeaning as0%{?rhel} == 6 from the previous example, and it tests whether apackage is built on RHEL6.

This conditional handles support for the rubypick tool. If the operating systemis Fedora version 19 or newer, rubypick is supported.

This conditional handles definition of the macros. If the%milestone or the%revision macros are set, the%ruby_archive macro, which defines the name ofthe upstream tarball, is redefined.

The%ifarch conditional,%ifnarch conditional and%ifos conditional arespecialized variants of the%if conditionals. These variants are commonlyused, so they have their own macros.

The%ifarch Conditional

%ifarch i386 sparc...%endif

The%ifnarch Conditional

%ifnarch alpha...%endif

The%ifos Conditional

%ifos linux...%endif