RPMBUILD(1)

πŸ’– NAME πŸ’–

okay so bestie, this is rpmbuild(1) β€” the General Commands Manual girlie you call when you need to build software like a pro. ✨

rpmbuild β€” Build RPM Package(s) πŸ’…


✨ SYNOPSIS ✨

rpmbuild -bSTAGE [options] SPEC_FILE ...

rpmbuild -rSTAGE [options] SOURCE_PACKAGE ...

rpmbuild -tSTAGE [options] TAR_ARCHIVE ...

rpmbuild {--rebuild|--recompile} [options] SOURCE_PACKAGE ...

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so rpmbuild builds software packages in the RPM format, and it does it in an automated and repeatable manner. no chaos, just vibes and reproducibility ✨

An RPM package file (or package) is like a little care package: it consists of an archive of files and metadata used to install or erase the archived files. The metadata includes helper scripts, file attributes, and descriptive information about the package. so organized πŸŽ€

Packages come in two varieties: binary packages, used to encapsulate software to be installed, and source packages, containing the source code and recipe necessary to produce binary packages. both iconic, both necessary


πŸ‘‘ OPERATIONS πŸ‘‘

  • -bSTAGE β€” Build STAGE from a spec file.
  • -rSTAGE β€” Build STAGE from a source RPM package.
  • -tSTAGE β€” Build STAGE from a tar(5) archive.
  • --rebuild, --recompile β€” Compatibility aliases for -ra.

STAGE is a single-letter argument that specifies the target stage to build. This also executes all preceding stages unless stated (or configured) otherwise. Additional steps beyond the one specified, such as clean up, may also execute. See BUILD PROCESS and OPTIONS for details. πŸ’«

πŸŽ€ Building packages πŸŽ€

Use these STAGE arguments to produce RPM package files ready for installation and/or distribution. getting fancy

  • a β€” Build both source and binary packages. This is not an actual stage but a combination of b and s, with the difference that packages built this way carry a "cookie" to indicate they came from the same build. On success, the build directory is removed.
  • b β€” Build just the binary packages. On success, the build directory is removed.
  • r β€” Build just the source package, checking for dynamic build dependencies. Executes the %prep and %generate_buildrequires stages before creating a package. See the DYNAMIC BUILD DEPENDENCIES section for details.
  • s β€” Build just the source package. No build stages are executed.

🌸 Partial builds 🌸

Use these STAGE arguments to build or test the encapsulated software without producing RPM package files. Useful when packaging new software in RPM format and/or troubleshooting. we love a test run

The corresponding spec sections are shown in parentheses where applicable.

  • p (%prep) β€” Unpack the sources and apply any patches.
  • d (%generate_buildrequires) β€” Check dynamic build dependencies and build the buildreqs.nosrc.rpm package if any are missing. Don't build anything else.
  • f (%conf) β€” Configure the sources. This generally involves the equivalent of ./configure.
  • c (%build) β€” Compile the sources. This generally involves the equivalent of make.
  • i (%install) β€” Install the binaries into the build root. This generally involves the equivalent of a make install. For historical reasons, this also includes the %check stage by default.
  • k (%check) β€” Run any checks specified in the spec. This generally involves the equivalent of make check.
  • l β€” Do a "list check" β€” the %files section from the spec file is macro expanded, and checks are made to verify that each file exists. This requires a previous build up to the %install stage to have taken place.

πŸ’… ARGUMENTS πŸ’…

  • SPEC_FILE β€” An RPM spec file.
  • SOURCE_PACKAGE β€” An RPM source package (with a .src.rpm extension).
  • TAR_ARCHIVE β€” A tar(5) archive, optionally compressed. To be directly buildable with rpmbuild, an archive must contain a spec file either by the name Specfile or one with a .spec extension.

🌈 OPTIONS 🌈

  • --build-in-place β€” Build from locally checked out sources in the current working directory. The build tree is set up as if %setup was used, but %builddir/%buildsubdir points back to the current working directory. %prep is skipped entirely.
  • --clean β€” Remove the build tree after the packages are made (default).
  • --nobuild β€” Do not execute any build stages. Useful for testing out spec files.
  • --nocheck β€” Do not execute %check build stage even if present in spec.
  • --noclean β€” Do not execute %clean build stage even if present in spec.
  • --nodebuginfo β€” Do not generate debuginfo packages.
  • --nodeps β€” Do not verify build dependencies.
  • --noprep β€” Do not execute %prep build stage even if present in spec. This assumes there has been another rpmbuild run in which %prep has been already executed.
  • --rmsource β€” Remove the sources after the build (may also be used standalone, e.g. rpmbuild --rmsource foo.spec). Note that by definition, NoSource and NoPatch files are not sources and so, are not affected by this option.
  • --rmspec β€” Remove the spec file after the build (may also be used standalone, e.g. rpmbuild --rmspec foo.spec).
  • --rpmfcdebug β€” Print debug information on file classification and dependency generation.
  • --scm=SCM β€” Select the SCM to use with %autosetup, if one is not set in the spec file. Note that not all values for SCM, e.g., patch (the default) and gendiff, git, or quilt work interchangeably with all other patches and options stated in the %autosetup line, especially option -pN.
  • --short-circuit β€” Skip straight to specified stage (i.e., skip all stages leading up to the specified stage). Only valid with -bc, -bi, and -bb. Useful for local testing only. Packages built this way will be marked with an unsatisfiable dependency to prevent their accidental use.
  • --with OPTION β€” Enable configure OPTION for build.
  • --without OPTION β€” Disable configure OPTION for build.

See rpm-common(8) for the options common to all operations. iykyk


⭐ BUILD PROCESS ⭐

Packages are built in a number of logical steps, outlined below. The steps are executed from top to bottom, skipping any that aren't applicable to the spec. clean, linear, slay

Those steps that produce (intermediate) build artifacts or diagnostic output are called stages. They are denoted by a single-letter identifier in parentheses. You can tell rpmbuild to stop the build process at any stage (see OPERATIONS for details).

Some steps are implemented as build scriptlets whose contents is dumped in the rpmbuild output for diagnostic purposes. Their names are shown in parentheses following any stage identifier, prefixed with % if they correspond to a spec section or directive.

Binary packages are produced separately for one or more platforms, called build targets. By default, the current platform is the only build target. This can be overridden with --target or by declaring a BuildArch in the spec. See also BUGS for some related known issues. πŸ‘€

  • Unpack source package or tar archive if either is given
  • Determine build targets and repeat following steps for each in turn
  • Load rpm-config(5), rpm-rpmrc(5) and rpmbuild-config(5) files for next build target
  • Parse spec file
  • Check static build dependencies
  • Setup build workspace
    • Create build directory and set %builddir to its path (mkbuilddir)
    • Export build environment to %builddir/rpmbuild.env file
  • Execute build scriptlets to populate %buildroot
    • Unpack sources and apply any patches (p, %prep)
    • Generate dynamic build dependencies (d, %generate_buildrequires)
    • Check dynamic build dependencies
    • Configure sources (f, %conf)
    • Compile sources (c, %build)
    • Install binaries into %buildroot (i, %install)
    • Read dynamic spec parts
    • Execute tests (k, %check)
  • Process files to be packaged
    • Populate file list for source packages
    • Populate file list for binary packages based on %files manifest(s)
      • Add regular entries from %buildroot
      • Copy special entries to %buildroot (%doc, %license)
      • Add special entries from %buildroot
    • Perform file classification
    • Generate runtime dependencies using rpm-dependency-generators(7)
    • Check file list against %buildroot (l)
  • Create packages
    • Write binary packages to disk (b)
    • Write source packages to disk (s)
  • Clean up
    • OBSOLETE: Perform explicit clean up (%clean)
    • Perform implicit clean up (rmbuild)

For more information on the syntax, see rpm-spec(5). πŸ’–


πŸ”₯ DYNAMIC BUILD DEPENDENCIES πŸ”₯

When the %generate_buildrequires stage runs and some of the newly generated BuildRequires are not satisfied, rpmbuild creates an intermediate source package ending in buildreqs.nosrc.rpm, which has the new BuildRequires, and exits with code 11. This package can then be used in place of the original source package to resolve and install the missing build dependencies in the usual way, such as with dnf-builddep(8). the plot thickens

Multiple layers of dynamic build dependencies may exist in a spec file; the presence of specific BuildRequires on the system may yield new BuildRequires next time a build is performed with the same source package. The easiest way to ensure that all dynamic build dependencies are satisfied is to run the -br option, install the new dependencies of the buildreqs.nosrc.rpm package and repeat the whole procedure until rpmbuild no longer exits with code 11. loop it till it slays

If the -br option is coupled with --nodeps, exit code 11 is always returned and a buildreqs.nosrc.rpm package is always created. heads up bestie


🧚 ENVIRONMENT 🧚

  • RPM_BUILD_NCPUS β€” Overrides autodetection for the number of CPUs to use for parallelized sections of the build.

πŸ’€ EXIT STATUS πŸ’€

On success, 0 is returned, a nonzero failure code otherwise.

Packages with a %generate_buildrequires section will return with code 11 when there are unmet DYNAMIC BUILD DEPENDENCIES. 😭

🌸 EXAMPLES 🌸

okay bestie, real talk, this is the part where it all clicks. here's how u actually use this thing πŸ’…

  • rpmbuild --rebuild hello-1.0-1.src.rpm

this one's giving "glow up from scratch" ✨ it builds binary and source packages straight out of the hello-1.0-1.src.rpm source package. no notes.

  • rpmbuild -bb --nocheck --with openssl hello.spec

builds binary packages from the hello.spec spec file, skips the %check stage if it's even in there, and flips on support for the openssl build conditional (that's assuming one is actually specified in the spec, bestie β€” if it's not, don't come for me 🫢).

  • rpmbuild -ta hello-2.0.tar.gz

builds binary and source packages out of the compressed hello-2.0.tar.gz tarball, assuming the archive has a legit spec file hiding in it (check TAR_ARCHIVE for the deets, iykyk).

  • rpmbuild -bc hello.spec

runs hello.spec up to and including the %build stage β€” i.e. no actual packages get made. it's the vibe check, not the whole personality. πŸ’€

  • rpmbuild -bi --short-circuit hello.spec

only executes the %install stage of hello.spec and skips every single stage before it. this assumes u already ran something that got u at least as far as %build (peep the previous example πŸ‘€). super useful so u don't have to do a whole full rebuild every time u're tweaking the %files section of a package. obsessed, honestly.


πŸŽ€ FILES πŸŽ€

see rpm-common(8), bestie. that's where the file lore lives. πŸ¦‹


πŸ’€ BUGS πŸ’€

okay so heads up, no cap: building a spec that declares a BuildArch may cause unexpected behavior. specifically:

  • macros defined before the BuildArch line get expanded twice, which can yield unexpected results β€” especially with %global. not it. 😭
  • using a --target that disagrees with the BuildArch results in undefined behavior. like, don't. fr fr. πŸ™ˆ

✨ SEE ALSO ✨

go read these too, they're iconic πŸ‘‘

and if u wanna go touch some grass (online), there's always:

http://www.rpm.org/

and that's the whole page, bestie!! this one's RPM 6.1.0, dated 2026-08-20, and it's called RPMBUILD(1) πŸ’– go build something gorgeous, u ate. periodt. πŸŽ€βœ¨πŸ¦‹

πŸ“¦ where this page comes from