Can’t recommend this gem enough.
I’ve successfully been using it for years to build (simple) Debian packages.
I just wish installing the gem on travis-ci wouldn’t take “so” long. Minor annoyance for such a useful tool.
I don’t know the specific problem, but I’ve found my gem installation time is greatly sped up if I add the –no-ri –no-rdoc flags to gem install.
And turn on travis caching so the install only happens when you bump the gem version.
Likewise, but to make rpms! It’s super flexible.
With my Debian Developer hat on, whenever I hear about fpm or other, similar tools, I have to sigh. While I understand the motivation behind them, I come accross people too often who want to make Debian Policy compliant packages with it, that also adhere to the RedHat packaging guidelines. They see a tool that can generate both debs and RPMs and think they found tho holy grail. This is all fine and all when you use the resulting packages internally. But if you want to get such packages into the official repositories… well, that is going to hurt.
And this is where my dislike stems from: fpm & friends provide an easy hack around learning packaging properly. It is a convenient, but counterproductive start for those who aim for the official archive. Yet, I see far too many people wildly confused when exposed to the native Debian tools, coming from fpm.
I don’t subscribe to the Get Things Done school of thinking, when that also ignores best practices while getting those things done. I’d rather get things done right, even if I have to spend a little more time learning. In the long run, learning has many more benefits than hacking stuff together.
Alternative viewpoint: I’ve been using Linux on and off for 20 years. I built a commercial product in three months a few years ago. One month was learning Go and building the functionality. The next two months were lost in a maze of man pages, decade-old html Q&A and newsgroup postings, trying to create proper debs and rpms for “proper” distribution. fpm was the only thing I could find to make it simple, it’s far more complicated than it should be.
Did you ever aim at official archives? If no, fpm is a good tool for the job. But if you ever plan to upload something to official Debian, fpm is a terrible waste of time.
I am not saying it is inherently bad - it isn’t. But it is terrible in the hands of those who wish to do more than quick hacks.
For commercial packages, you can ignore so many things, that learning the Debian way is - as you found - not worth it. I used to work for a company who provided debs for its software. I looked once, and almost cried. But they worked, users were happy, so they had no interest in making them better. Nothing wrong with that, and I was not criticising this aspect of fpm.
It’s GPL licensed so having an official package for distros was something I wanted to see eventually. I gave up because it makes no sense for me to spend months so I can give away something for free the “right” way.
what about the proper debian way to do packages is incompatible with fpm? (as in, why could some debian person not just contribute a better version of fpm’s debian packager?)
I am sort-of surprised that there is no mention of nix packages (or guix).
I wonder if this is because nix packages are already so easy to create? I made my first couple nix packages in under 10m each.
After thinking about it, I realized why this is. Nix packages are more akin to Debian RULES files than to binary package formats; they are not intended to contain binaries, and except in exceptional cases they don’t even contain source, just point to where on the web it can be found (with a hash, for security). While a couple of the formats fpm supports do have source files (“python”, “ruby”, “pear”), most are for binaries.
I think this also explains why fpm doesn’t support BSD ports files, although I don’t know for sure that those are analogous.
Irony: it’s a gem package itself. :)
The real question is can fpm fpm itself into a deb? It it self hosting?
I’ve used this tool and I’d recommend it only as a last resort - the packages it builds aren’t much better than tarballs. I’ve found that I can almost always find the packaging scripts for a “real” Fedora or Debian package of the code I want to install. The advantage to leveraging the upstream packaging is that the config files, log files, libraries, etc etc all end up in the right place.