For any given platform, you're likely to see a special reinvention of software packaging and distribution. OS distributors do it: Red Hat's rpm, Debian's deb, FreeBSD's pkg_add and friends, Solaris' SRV4 packages. Software platforms do it: ruby has rubygems, python has eggs, node has npm, etc. The most maddening part is that most of these things are solving the same problem but are totally incompatible!
Incompatible tooling hurts everyone, but it gets worse.
High barriers are built and called "best practices" or "policy" that slow or discourage new and existing users from making good use of packaging tools. With high knowledge barriers made worse by incompatibilities in naming things (such as 'iteration' vs 'release' vs 'revision' all meaning the same thing), I certainly feel heavily discouraged in learning packaging tools. Once you've invested in, say, redhat's packaging systems, you're effectively vendor-locked because the cost of learning an alternative system is so high.
With fpm, I set out to solve much of these pains. Nearly 3 years old, fpm has quickly become a strong, community-driven project to help many folks build packages without needing to suffer high knowledge barriers and without sacrificing flexibility.
fpm isn't a new package format, it's just a new and simpler tool for building packages or converting packages from one type to another. At time of writing, fpm currently supports 14 different package formats (deb, rpm, cpan, rubygems, python pypi, solaris srv4, osx, etc).
This talk will introduce the problems with packaging as well as how fpm exists to solve them. It will also cover lots of neat tricks the community has found for doing cool and useful things with fpm.
elasticsearch
tsubakimoto_s
nozomiito
mmclsntr
matsumoto_r
marikashiotsuki
okuzawats
sr2mg4
.png){kind=icon}
pharma_x_tech
interu
line_developers
yujisoftware
skrb
bcantrill
lemiorhan
shpigford
danielanewman
malarkey
eileencodes
yeseniaperezcruz
thekraken
zenorocha
philnash
quramy
sugarenia