Convert Any File to RPM Online (Building the Payload Half of a Package, Not the Whole Thing)

A Plain File Has None of What an RPM's Header Section Requires

Building an RPM around an arbitrary file means constructing all four of the format's sections in order: a 96-byte Lead identifying the file by its magic bytes, a Signature section carrying a digest and (optionally) a GPG signature, a Header holding every piece of package metadata, and a Payload that's a compressed cpio archive of the file itself. The Payload part is the easy half — it's just the file, cpio-wrapped and compressed with gzip, XZ, or zstd depending on which tool built it. The Header is the part a plain file never comes with any information for on its own: a package name, a version string, a release number, a target architecture, and a one-line summary are all required fields the RPM format expects, and none of them can be inferred correctly from a file's bytes alone.

This is the core reason converting an arbitrary file straight to RPM isn't really analogous to converting it to ZIP or TAR — a ZIP or TAR archive just needs the file's name and bytes, while an RPM needs a maintainer to have made a set of packaging decisions first. Any tool that produces an RPM from a plain file or folder without a hand-written .spec file has to supply reasonable defaults for those Header fields on the packager's behalf, which is exactly the gap the fpm tool ("Effing Package Management," written by Jordan Sissel) was built to close.

Two Genuinely Different Paths Lead to the Same .rpm Extension

The traditional route is rpmbuild reading a .spec file — a text recipe listing the package name, version, dependencies, install scriptlets, and the exact file list — and compiling all of that into a proper Header before writing the Payload. Fpm takes the opposite approach: its command syntax, fpm -s <source-type> -t rpm, lets someone point directly at a source (a plain directory, an existing .tar.gz, a Python package, a Ruby gem, or even another package format like .deb) and skip writing a spec file entirely, with fpm generating the Header fields from command-line flags like --name, --version, and --architecture instead.

Because fpm's own documentation confirms it supports both reading from and writing to nearly a dozen package formats — including tar, zip, deb, and rpm as both source and target types — the same command that builds an RPM from a plain directory of files can just as easily take an existing .tar.gz or .zip archive as its input, unpacking it internally and repackaging its contents as the RPM's Payload without anyone touching rpmbuild or a .spec file at all.

When no architecture is specified and the files being packaged are plain data, scripts, or documents rather than compiled binaries, RPM's convention is to mark the package "noarch," a designation meaning it can install on any CPU architecture the target distribution supports — the correct default for most any-file-to-RPM conversions, since a random text file, image, or document has no architecture dependency to declare in the first place.

What Wrapping a File as an RPM Actually Gets You

• Gain — installability through a package manager: once the Header carries a valid name and version, dnf, yum, or zypper can install, track, and later cleanly remove the file the same way as any other package.
• Gain — automatic dependency declaration, when the source format carries it: converting from another package format like .deb, fpm can translate some dependency fields across, though not perfectly, since dependency naming conventions differ between ecosystems.
• Lose — real install scriptlets, unless explicitly added: %pre, %post, %preun, and %postun scripts don't exist unless a spec file or fpm's --before-install/--after-install flags define them; a plain file wrapped as an RPM gets none by default.
• Lose — a meaningful dependency graph, for a genuinely standalone file: a converted text file or image has no real software dependencies, so its Header's Requires field is typically empty, unlike a package built from compiled software.
• Gain — a GPG-verifiable Signature section, if signing is configured: rpm --addsign or a build system's signing step can attach a cryptographic signature after the RPM is built, giving downstream systems a way to verify it wasn't altered.
• Cost — packaging guideline warnings: tools like rpmlint routinely flag RPMs built without a proper spec file for missing fields such as %license or %doc, or for unusual file permissions inherited directly from the source files.

Where Spec-Free RPM Building Is Actually Documented and Used

Fpm is distributed as a Ruby gem and documented on its own Read the Docs site, with a dedicated page specifically for its RPM target covering flags like --rpm-os, --rpm-summary, and --rpm-digest for choosing the header digest algorithm. It's commonly used in continuous-integration pipelines specifically because it lets a build script generate an installable RPM from a compiled application's output directory without maintaining a separate .spec file alongside the source code, something rpmbuild alone can't do.

rpmbuild itself remains the tool used for anything that needs a real, guideline-compliant package — it's included in the rpm-build package on Fedora, RHEL, and openSUSE, and its --nodeps and --short-circuit flags exist specifically to support iterative packaging work where a full dependency-checked build isn't needed on every single attempt. checkinstall, an older third-party tool, takes a completely different approach: it runs a project's own make install command under close monitoring (via a technique often described as "installwatch"), records exactly which files that command wrote to the filesystem, and then builds an RPM, or a .deb on Debian-based systems, containing just those tracked files — useful for packaging software that only ships a traditional Makefile with no RPM-specific build support at all.

Documented Problems Building an RPM Around Files That Were Never Meant to Be One

A frequent complaint with fpm-built RPMs is a missing or incorrect architecture tag causing the resulting package to be rejected or misfiled by a repository management tool — since fpm won't infer architecture from file contents automatically, forgetting the --architecture noarch flag on a data-only package can leave it tagged with the build machine's own architecture (commonly x86_64) even though nothing inside it actually requires that CPU type.

A second, well-documented issue involves rpmlint flagging spec-free RPMs for missing standard fields that Fedora's and openSUSE's own packaging guidelines expect, most commonly a missing %license or %doc entry and a missing package Summary or Description beyond a placeholder string — these warnings don't stop the RPM from installing, but they do block acceptance into official distribution repositories, which require a properly maintained .spec file rather than a quick fpm-generated package.

A third pattern shows up around file permissions and ownership carried straight through from the source files or directory being converted — since fpm and similar tools generally preserve whatever mode bits and ownership the input already had rather than normalizing them, a directory built on one system with unusual permissions can produce an RPM that installs files with the same unexpected permissions on the target system, unless explicitly overridden with fpm's own --rpm-user and --rpm-group flags.

A fourth issue involves attempting to install an RPM built without any dependency declarations onto a system where the packaged software actually does need a library that was never listed — since a converted plain file or generic directory carries no dependency metadata unless it's explicitly added with fpm's --depends flag, the package installs successfully but the software inside it can fail at runtime for a completely different, dependency-related reason that the install step itself never caught.

Building From a Spec File Against Building With FPM

Common Questions About Turning a File Into an RPM

Do I need to write a .spec file to build an RPM?
Not necessarily. Tools like fpm can build a valid RPM directly from a plain directory or an existing archive using command-line flags for the name, version, and architecture instead of a hand-written spec file, though the result is generally less complete than a proper spec-based package.

Will the resulting RPM have any dependencies listed?
Only if they're explicitly added. A converted plain file or directory carries no dependency information on its own, so the package's Requires field stays empty unless a flag like fpm's --depends is used to declare dependencies manually.

Why does my quickly built RPM get flagged by rpmlint?
Rpmlint checks packages against Fedora's and openSUSE's own guidelines, and a package built without a proper spec file commonly triggers warnings for missing fields like %license, %doc, or a real package description rather than a placeholder string.

What architecture should a data-only file get tagged with?
Noarch, RPM's designation for packages with no compiled, CPU-specific binaries inside them — the correct choice for a plain document, script, or media file, since it lets the package install on any architecture the distribution supports.

Can I convert an existing ZIP or TAR archive straight into an RPM?
Yes. Fpm accepts tar and zip archives as source types directly, unpacking them internally and repackaging the contents as the RPM's Payload without needing a separate extraction step first.