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: 71838c7d4cf444a5bac39b19cc3e68e5e73acb5b
Page Name:Howto
Date: 2014-12-15 00:08:41
Original User: mario
Mimetype:text/x-markdown
Parent: 0da4ff5013b6c9244e09f8e499fb5cecdc81f998 (diff)
Next 74b785ada5458990dc612fdf8a81b2201983378e
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 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: