I think it would make sense to provide pre-build packages for few popular distros (Ubuntu, CentOS, Arch). There are some tools that make it much easier, i.e. fpm (https://github.com/jordansissel/fpm).
In Exponent – Build native apps in JS that work across both iOS and Androidjordansissel
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, 5:05:26 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
9 sourcesBecause then you also need to host a feed, and keep it updated when new releases become available, and keep it updated when new plugin releases become available, and ensure the feed stays up, and maintain patches, and maintain required dependencies. All the things that package maintainers (thank you!) do for the ecosystem. Unless there's substantial gain why not just stick with Nginx?
For what it's worth though FPM is awesome, and has made my life better a number of times. If you have to have software that isn't packaged and you aren't familiar with packaging, look into FPM.
https://github.com/jordansissel/fpm
In Caddy 0.9 Released with All New CoreFPM[1] will get you most of the way there, but your packages are still going to seem a bit out of place unless you make distro specific changes.
[1] https://github.com/jordansissel/fpm
In Apex lets you build, deploy, and manage AWS Lambda functions with ease> However, when you have something like RVM which is used across several major operating systems, and hundreds of different flavours, each with their own quirks and package managers it suddenly gets difficult to manage each of these.
I'm not sure that really changes with an install script. You've got several major operating systems, hundreds of flavours with all kinds of quirks. And you don't even know what shell you're really running on. How do you know your install script will work in any reasonable way?
For example, all reasonable package managers will make sure existing files aren't overwritten, existing configs are not modified, all ownership/modes are reasonable by default. Sure, you can override that in post-install script, but it will stand out that you're doing something non-standard, because there's a post-install script.
> how
Read the rest
can we make it easy to install something, while still being safe and maintainable?
Have you seen FPM? (https://github.com/jordansissel/fpm) It provides a nice, simple(ish) abstraction over all the packaging craziness.
> Are you crazy!? This isn't an issue. If you don't trust the installer, you sure as hell can't trust the product.
I do not trust either the installer or the app. If I have a simple package to deploy, I can: 1) check that there are no post/pre-install scripts 2) install the files on the system 3) contain/sandbox them using selinux / grsec / apparmor / chroot / separate user. I cannot easily do the same thing with an installer script, which by definition wants to merge foreign files into my running system.
Even better, it's in the interest of app creator to care about this and provide sandboxing by default, even if they trust the app.
FPM pretty much solves this https://github.com/jordansissel/fpm
In Show HN: Make Ubuntu/Debian packages for Nginx with your patches in one commandOr use FPM (https://github.com/jordansissel/fpm/wiki) and abstract the whole packaging idea. linux and mac packages supported.
In Diff So Fancy: make Git diffs look goodThis is a tutorial for building quick one-off packages that won't ever be accepted by debian but that you can use with your own servers.
If you want to do that, you will be better off using Jordan Sissel's fpm tool: https://github.com/jordansissel/fpm
It can take any project and quickly package it into a .deb, .rpm, .whatever package.
In Debian Packaging Tutorial – Feedback WelcomeIf on the other hand your goal is not to get a package in Debian, but only to quickly make a deb file, check out fpm: https://github.com/jordansissel/fpm.
In Debian Packaging Tutorial – Feedback Welcome