Cross package maker. DEB/RPM generation or conversion. Derived from jordansissel/fpm.

⌈⌋ branch:  cross package maker


Update of "Howto"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: 5ba9e34b85b5c9990f18b5e297a8700fae4a0e10
Page Name:Howto
Date: 2014-12-24 14:48:01
Original User: mario
Mimetype:text/x-markdown
Parent: 3134a8f3a4445f35a1e69013dc06876faff70374
Content

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 needs simple command-line options instead of 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 basically reads in all the files and bundles them asis. The target can be one of deb,rpm,zip,ipk,exe. Version, architecture, maintainer all have short options, while the --longer ones are self-explanatory.

See also the fpm wiki on github for more examples 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:

--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

A separate .fpm file thus reduces the packaging process to just:

fpm -s src -t deb,rpm main.py

Notably you can also utilize the --input flag, to externalize the file list. (Often best suited for the dir module.)

Embed within a Makefile

For many projects it might make sense to embed the fpm-packaging recipe as regular section into 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 requiring sudo make install incantations.

xpm multi-targets

One benefit of the xpm branch is to avoid fordone shell loops as shown above. The -t target type can be a comma-separated list now:

fpm -t deb,rpm,exe,pkg,zip

For compatibility with curent fpm, please just use individual -t calls for general build scripts however.

Other introductions

FPM is widely used, therefore covered in other tutorials as well: