CentOS still has python2.6 as the default. Several people I know who use CentOS with python just build their own python2.7 anyway -- at $dayjob, I build python2.7 and package it up with fpm[1] and drop it in our internal repo.
[1]: https://github.com/jordansissel/fpm
In Fedora Linux will switch to Python 3 by defaultjordansissel
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, 7:24:48 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
8 sourcesI don't particularly like homebrew compared to the Linux distro package managers, but I have found it convenient for messing around on my Macbook due to the large existing library.
A couple of other interesting projects in the Linux software installation space, which I have been using recently:
* fpm ("Effing Package Management"): https://github.com/jordansissel/fpm/wiki
Can be used to generate deb or rpm packages given a source directory or existing package of various types. (For example, generate an RPM from a Rubygem.)
I use this frequently to quickly create distro packages from software which only has source available, then put them in a yum repository on S3 for my private projects. (Creating package repositories is so easy, and signing them isn't much harder. It's really worth doing.)
* EasyBuild: https://github.com/hpcugent/easybuil
Read the rest
d
EasyBuild automates building software from source, and provides a framework for automating a variety of complex build processes. It's targeted at high-performance scientific computing, where many of the applications have arcane or bizarre build processes, and includes modules for a huge variety of scientific apps.
The big advantage (IMO) is that EasyBuild integrates with Environment Modules [1], which makes it easy to work with many different versions of the same software side-by-side. EB doesn't put everything in the same tree; each package is installed into its own directory and Environment Modules is used to manage the PATH, LD_LIBRARY_PATH, etc. "module load hdf5/1.8.11" and you're good.
I use it extensively both on my laptop and on some of the compute clusters I manage, where users frequently need to be able to switch library and application versions quickly and easily.
One workflow I've been experimenting with recently: Use EasyBuild to build and install all packages into locations in /opt on a dev machine, then use fpm to package them and upload into my repo. Reproduce the system by installing the relevant packages from yum, and still get the flexibility of using Environment Modules.
[1] http://modules.sourceforge.net/
I like to get the best of both pip and the distro's native package manager ...
https://github.com/jordansissel/fpm
In Musings about Debian and PythonAfter attempting the distribution of a command line application via Rubygems I came to the following conclusion: Any application not intended exculsively for Rubyists should not be distributed via Rubygems.
Another option could also be to convert gems (and dependency gems) to deb or rpm packages https://github.com/jordansissel/fpm/wiki/ConvertingGems
As far as I know, the Foreman project utilizes this approach http://deb.theforeman.org/pool/precise/stable/f/foreman/
In On Distributing Command Line Applications: Why I Switched From Ruby to GoThis is stupid. The entire reason that people have issues with multiple versions of software is that they had to "roll their own" and don't bother to update it, thus they hit incompatibilities and need some sort of "bundling" utility like this.
If you're running any form of Unix, it's very likely that you already have a package management system. It's also likely that system has more features, and is better designed from a management and consistency perspective than any one of CPAN and it's descendants (gem, cabal, etc.).
A much better solution - either make your own packages, or use a tool like FPM (https://github.com/jordansissel/fpm) to make native packages, then deploy the result as you would any other package.
I hope for an era when running CPAN or gem interacts with the package manager, building a real OS-level package and install
Read the rest
ing/deploying it, rather than the current "you need to run this script incantation on every production machine, oh, and you need the whole toolchain too" idiocy.
Don't use `checkinstall`, use FPM:
https://github.com/jordansissel/fpm
In Packaging built softwareA nice way to build apt repositories is to use fpm. https://github.com/jordansissel/fpm
Although for just installing rails, using rubygems is the way to go, IMHO.
In Abandoning RubygemsWithout Chef there would be no way for me to rollout a new server in our cluster. Investing time into Chef was one of the greatest things I ever did. Chef is the best documentation of our infrastructure. The second best tool I'm using is fpm[1] to make custom debian packages.
[1] https://github.com/jordansissel/fpm
In How I spend my first 5 minutes on a server