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 atar(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 ofbands, 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%prepand%generate_buildrequiresstages 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 thebuildreqs.nosrc.rpmpackage 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 ofmake.i(%install) β Install the binaries into the build root. This generally involves the equivalent of amake install. For historical reasons, this also includes the%checkstage by default.k(%check) β Run any checks specified in the spec. This generally involves the equivalent ofmake check.lβ Do a "list check" β the%filessection 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%installstage to have taken place.
π ARGUMENTS π
SPEC_FILEβ An RPM spec file.SOURCE_PACKAGEβ An RPM source package (with a.src.rpmextension).TAR_ARCHIVEβ Atar(5)archive, optionally compressed. To be directly buildable withrpmbuild, an archive must contain a spec file either by the nameSpecfileor one with a.specextension.
π OPTIONS π
--build-in-placeβ Build from locally checked out sources in the current working directory. The build tree is set up as if%setupwas used, but%builddir/%buildsubdirpoints back to the current working directory.%prepis 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%checkbuild stage even if present in spec.--nocleanβ Do not execute%cleanbuild stage even if present in spec.--nodebuginfoβ Do not generate debuginfo packages.--nodepsβ Do not verify build dependencies.--noprepβ Do not execute%prepbuild stage even if present in spec. This assumes there has been anotherrpmbuildrun in which%prephas 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,NoSourceandNoPatchfiles 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) andgendiff,git, orquiltwork interchangeably with all other patches and options stated in the%autosetupline, 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)andrpmbuild-config(5)files for next build target - Parse spec file
- Check static build dependencies
- Setup build workspace
- Create build directory and set
%builddirto its path (mkbuilddir) - Export build environment to
%builddir/rpmbuild.envfile
- Create build directory and set
- 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)
- Unpack sources and apply any patches (
- Process files to be packaged
- Populate file list for source packages
- Populate file list for binary packages based on
%filesmanifest(s)- Add regular entries from
%buildroot - Copy special entries to
%buildroot(%doc,%license) - Add special entries from
%buildroot
- Add regular entries from
- 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)
- Write binary packages to disk (
- Clean up
- OBSOLETE: Perform explicit clean up (
%clean) - Perform implicit clean up (
rmbuild)
- OBSOLETE: Perform explicit clean up (
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
BuildArchline get expanded twice, which can yield unexpected results β especially with%global. not it. π - using a
--targetthat disagrees with theBuildArchresults in undefined behavior. like, don't. fr fr. π
β¨ SEE ALSO β¨
go read these too, they're iconic π
gendiff(1)popt(3)rpm(8)rpm-common(8)rpmbuild-config(5)rpm2cpio(1)rpmkeys(8)rpmspec(1)rpmsign(1)rpm-setup-autosign(1)rpm-macros(7)
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
- ubuntu stonking: rpm 6.1.0-1 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms