Update of "Howto"
Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Artifact ID: | 71838c7d4cf444a5bac39b19cc3e68e5e73acb5b |
---|---|
Page Name: | Howto |
Date: | 2014-12-15 00:08:41 |
Original User: | mario |
Mimetype: | text/x-markdown |
Parent: | 0da4ff5013b6c9244e09f8e499fb5cecdc81f998 (diff) |
Next | 74b785ada5458990dc612fdf8a81b2201983378e |
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 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
Examplary the make install DESTDIR= method
fpm: love packaging!! and the original Introducing FPM - Effing Package Management are still relevant