Wiki page
[Howto] by
mario
2014-12-15 00:08:41.
D 2014-12-15T00:08:41.775
L Howto
N text/x-markdown
P 0da4ff5013b6c9244e09f8e499fb5cecdc81f998
U mario
W 3865
### How to use fpm?
The virtue of fpm is that it vastly simplifies both RPM and DEB creation. You don't neccessarily need the distro-specific tools even (well, `rpmbuild` still).
And it just accepts terse command-line options to forgo crafting extra .spec/control files:
fpm -s dir -t deb,rpm \
-n packagename -v 1.0.0 -a x86 \
-m maintainer@example.com --url http://example.com \
--description "Package that does all the things." \
src/*
# (The backslashes above are just used to mask linebreaks.)
The `dir` module just reads in all the files and bundles them as-is. The target can be one of deb/rpm/zip/tar/exe, or for *xpm* a comma-separated list. Version, architecture, maintainer all have short options, while the --longer onss are self-explanatory.
See also the [fpm wiki on github](https://github.com/jordansissel/fpm/wiki) for a few more samples, and the complete option reference (`--help`).
### Using an `.fpm` file to reduce options
Instead of relisting the flags on each invocation, you can also just create a `.fpm` file in your source tree. It ought to list fpm flags verbatim:
-s dir
-t deb,rpm
--force
--name PACKAGENAME
--version 1.0.0
--iteration 1
--description "All the things."
--license BSDL
--category Multimedia
--vendor xyz@example.com
--maintainer xyz@example.com
--depends python
--prefix /usr/local
--verbose
src/*
pixmaps/*
It's best to leave out fpms `-t` though, to allow generating one package type after another.
### Embed within a Makefile
For many projects it might be resourceful to make the fpm-packaging recipe a regular section of the `Makefile`. It's basically an embellished shell script therein.
Instead of distributing a `.fpm` alongside, it's possible to just add a few variable fields topmost the Make script:
CCFLAGS=...
...
PKNAME="yourpackagename"
VERSION="0.1.2.3"
URL="http://example.com/project/name"
DESCRIPTION="X11 tool which does all the things"
And construe a target such as:
pack:
for PACK in rpm deb; \
do \
fpm -t $$PACK -n $(PKGNAME) -v $(VERSION) \
--description $(DESCRIPTION) -m y@x --category x11 --url $(URL) \
-f -s dir \
./xapp=/usr/bin/xapp \
./pixmaps=/usr/share/xapp/pixmaps; \
done
Note that this prevents the description from containing linebreaks easily. It's still suitable to allow users to quickly build a system package instead of manual `sudo make install` incantations.
### xpm multi-targets
**Note that this is just a planned feature at this point.** But the rationale for `xpm` is also to eschew multiple `fpm` calls for different `-t` target types. While as depicted above, it's entirely feasible to wrap it in a `for`…`done` shell loop/script.
For compatibility with regular fpm, please just use individual `-t` calls for general build scripts.
### Other introductions
FPM is widely used, hencefore is covered in other tutorials well:
* [DigitalOcean: How To Use FPM To Easily Create Packages in Multiple Formats](https://www.digitalocean.com/community/tutorials/how-to-use-fpm-to-easily-create-packages-in-multiple-formats)
* Examplary the [make install DESTDIR= *method*](http://midactstech.blogspot.de/2014/05/install-fpm.html)
* [fpm+reprepro=Awesome](https://blog.akendo.eu/fpm-plus-reprepro-equals-awesome/)
* [fpm: love packaging!!](https://speakerdeck.com/elasticsearch/fpm-love-packaging) and the original [Introducing FPM - Effing Package Management](http://www.semicomplete.com/blog/geekery/fpm.html) are still relevant
Z 5e678ead9e79331a637bdeae0d0977da