fpm is the solution: https://github.com/jordansissel/fpm
In Give me back my sanity: How I had to install Pandoc in a CentOS Docker containerjordansissel
fpm
Ruby2011–2025
jordansissel / fpm
fpm
Effing package management! Build packages for multiple platforms (deb, rpm, etc) with great ease and sanity.
67Distinct people
80Mentions
1Explicit recommenders
11.5KGitHub stars
What to know before exploring
What it is
Effing package management! Build packages for multiple platforms (deb, rpm, etc) with great ease and sanity.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Yeah, there's more than a whiff of entitlement to that phrasing. If you haven't seen it, I highly recommend looking at fpm for packaging. Unless you're doing something weird or…
_lqaf used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:01:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year80 dated mentions
Observed mentions: 2011-08-27 17:21:25 UTC to 2025-05-26 22:47:13 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
fpm
The goal of fpm is to make it easy and quick to build packages such as rpms,
debs, OSX packages, etc.
fpm, as a project, exists to help you build packages, therefore:
If fpm is not helping you make packages easily, then there is a bug in fpm.
If you are having a bad time with fpm, then there is a bug in fpm.
If the documentation is confusing, then this is a bug in fpm.
If there is a bug in fpm, then we can work together to fix it. If you wish to
report a bug/problem/whatever, I welcome you to do on the project issue tracker.
You can find out how to use fpm in the documentation.
You can learn how to install fpm on your platform in the installation guide.
Project Principles
Community: If a newbie has a bad time, it's a bug.
Engineering: Make it work, then make it right, then make it fast.
Capabilities: If it doesn't do a thing today, we can make it do it tomorrow.
Backstory
Sometimes packaging is done wrong (because you can't do it right for all
situations), but small tweaks can fix it.
And sometimes, there isn't a package available for the tool you need.
And sometimes if you ask "How do I get python 3.9 on RHEL 8?" some unhelpful
trolls will tell you to "Use another distro"
Further, job switches have me flipping between Ubuntu and CentOS. These use
two totally different package systems with completely different packaging
policies and support tools. Learning both was painful and confusing. I want to
save myself (and you) that pain in the future.
It should be easy to say "here's my install dir and here's some dependencies;
please make a package"
The Solution - FPM
I wanted a simple way to create packages without needing to memorize too much.
I wanted a tool to help me deliver software with minimal steps or training.
The goal of FPM is to be able to easily build platform-native packages.
With fpm, you can do many things, including:
Creating packages easily (deb, rpm, freebsd, etc)
Tweaking existing packages (removing files, changing metadata/dependencies)
Stripping pre/post/maintainer scripts from packages
Things that should work
Sources:
gem (even autodownloaded for you)
python modules (autodownload for you)
pear (also downloads for you)
directories
tar(.gz) archives
rpm
deb
node packages (npm)
pacman (ArchLinux) packages
Targets:
deb
rpm
solaris
freebsd
tar
directories
Mac OS X .pkg files (osxpkg)
pacman (ArchLinux) packages
Read the full README on GitHubWhat Hacker News says
14 sourcesDEB packages are very complicated
Not really, it's just a tar file with some metadata. Using fpm¹, making packages from a directory is extremely simple. I've been building internal packages from our different components, and the build script only has three or four lines. And besides, even Dockerfiles often use apt/yum.
¹ https://github.com/jordansissel/fpm
In Aptly: Owning Your Debian DistributionI think the solution is to separate the problem into two parts
- The "puts things on disk" part (posix "install" or a low level tool like dpkg or rpm is most like this)
- The "determine what needs to be installed" part, (aptitude, yum)
I'm all for a per-language or system version of the latter, but once that's done, you should generate packages installed by the former.
Heck, wrap all the commands (cp/mv/install/chmod/chown/etc.) that write stuff to permanent places on disk to actually do "add to a package", give it a basic name/version number, and have the low level tool handle adding/removing it from the system (or multiple systems, or deploy it, etc.). All the dependencies, compatibility, etc. are handled by the higher level system.
This gets you the best of both worlds - system level packages, and the ability to install whatever you n
Read the rest
eed. FPM (https://github.com/jordansissel/fpm) is a pretty good example of this philosophy.
But, instead, we get every punk ass CPAN descendent spraying it's crap all over the filesystem, needing the whole build environment installed, touching the internet in weird ways that don't guaranteed repeatable behavior, etc. sigh
Would something like https://github.com/jordansissel/fpm help?
In Show HN: BigScreen sends pictures and music from OS X to ChromeCastdebs built with fpm[1] have been working for me. Unless you need something particularly complex, it should just be a matter of setting up a directory with the right layout and calling fpm with a couple of parameters.
[1] https://github.com/jordansissel/fpm
In TerraformThere's nothing like a good old deb (or rpm) package. Learn fpm[1] and bundle your dependencies instead of hoping that they get there.
[1] https://github.com/jordansissel/fpm
In Python 3 can revive PythonIt can point to Maven dependencies that are downloaded on the first launch
You wouldn't do this for a production deployment, right? Application starup that may or may not require access to the artifact repository to complete successfully. When that idea bounces around my developer neocortex, my sysadmin hindbrain starts reaching forward to strangle it.
And if you're not going to do it in production, doing it in development means having a gratuitous difference between development and production, which, again, is something i have learned to fear.
A zip with startup scripts is OK, but it requires installation.
'gradle installApp' works out of the box, and 'installs' the jars and scripts in your build directory, which is all you need to run locally. It's work of minutes to write an fpm [1] invocation that packages the output of installApp as
Read the rest
an operating system package, which you can then send down the pipe towards production. This is simple, easy, standard, and fully integrated with a world of existing package management tools. Why would i use Capsule instead of doing this?
[1] https://github.com/jordansissel/fpm
@jarofgreen nice of you, but I think you got me a little wrong, or I wasn't clear enough. My main message regarding opensource was:
> Open Source doesn't mean that you cannot put a price tag on it.
The other things could be done, but you're right, they don't fall under the strict definition of opensource. It would require a different license :)
Oh, btw, the op should take a look at https://pkgr.io/ and https://github.com/jordansissel/fpm
In Introducing OpencallPackaging is a real pain, kind of a schlep. One project, which solved a lot of problems for me was https://github.com/jordansissel/fpm.
One edge-case, where fpm cannot help by itself, occurs in the python (w/ C-bindings) world, when your dev and prod environments use different libc versions. I got around that issue by running fpm inside a VM, which matches the libc version of the target system.
But it's still not as easy as it can be - so pkgr.io looks promising.
In Pkgr.io: Easy way to get a Debian package out of any appSo how do I rebuild the compost heap infrastructure that I used to build my environment?
This.
Has anyone ever tried https://github.com/jordansissel/fpm FPM yet?
In Just what we need. Another package manager.Why not just build your own packages? fpm[1] is very simple to use.
[1] https://github.com/jordansissel/fpm
In Fucking Shell ScriptsPackages are great because they simplify automation. Once you've got a package built and uploaded to a repository, you can install it across a large fleet of machines one-line of Chef or Puppet code.
There are some pitfalls, however:
* It can be time-consuming dealing with the arcane details of Debian package metadata or RPM spec files. If you're deploying your own application code, you're likely better off using fpm to generate a package from a directory tree:
https://github.com/jordansissel/fpm
* If you have a complex stack, e.g., a specific version of Ruby and a large number of gem dependencies, you should avoid trying to separate things into individual packages. Just create a single Omnibus-style package that installs everything into a directory in /opt:
https://github.com/opscode/omnibus-ruby
* Maintaining build machines and reposit
Read the rest
ory servers takes ongoing effort. Shameless plug: This is why I created Package Lab---a hosted service for building packages and managing repositories. Currently in private beta and would love feedback:
https://packagelab.com/
I'm lazy when it comes to these things, so I use FPM. It's great if you're dealing with RPM and .deb packages (and a few others). I saw someone else (vacri) mention it in this thread, but it definitely deserves consideration if you want to side-step setting up a packaging environment.
Link: https://github.com/jordansissel/fpm
In Who helps your Linux distribution run smoothly? Thank a packager todayI prefer native system packages to tarballs, so here's a script [1] to generate .deb and .rpm packages using Jordan Sissel's FPM [2] (gem install fpm).
[1] https://gist.github.com/rasschaert/8915657
[2] https://github.com/jordansissel/fpm
In Announcing gitsh: A dedicated shell for git commands