Pet Project: One Step Asterisk Compile On CentOS 7

Home » Asterisk Users » Pet Project: One Step Asterisk Compile On CentOS 7
Asterisk Users 4 Comments

Hi all, I thought I’d share I script I made (based on some of Leif’s works)
that lets you download, compile and install Asterisk all in one go;
and then removed the dev tools used.

We use it quite a bit to provision systems using Ansible, but it is easier than remembering everything every time even if you are using a shell.

At the moment I have scripts for CentOS 7 and Asterisk 13, but plan to port them to other versions of Asterisk as there is a need to do so. Contribs welcome!

Project located at

Thanks l.

4 thoughts on - Pet Project: One Step Asterisk Compile On CentOS 7

  • 1. Asterisk basically has such a script inside.

    2. Asterisk has an RPM package. An RPM package is exactly a reproducible build (listing dependecies, and such).

    3. You are reinventing RPM. Badly. Do you people really want to run:
    – As root
    – A huge blob nobody can inspect
    – that is executable, and hence has tons of places to add nice hooks

    Learn how to use rpmbuild.

  • 2016-06-14 17:44 GMT+02:00 Tzafrir Cohen :

    It is – as you say – inside. This is outside and does the download for you.

    It’s true. They are very interesting, especially if you are a historian of software.

    If you need something less, say, “vintage”, you may need to compile it yourself.

    I personally happen to have shipped RPMs for about 10 years now. But building a RPM might be overkill if you are deploying a test, throwaway box, or just once for a Docker image. Of course I would not use this as an RPM substitute, and if I were to use something like this I’d fork it or at least read it (it is maybe 20 lines). YMMV.

    And IIRC there is more places to ship “nice hooks” into a binary you ship as an RPM than in a shell script that does what you would manually from the terminal!


  • RPM is one of the common formats to describe building of a package. There are other such similar formats, but if you’re on CentOS, RPM is already included with the platform, and hence it makes sense to use it.

    An RPM package is an archive (technically: cpio. But you don’t get direct access to that) with a small dictionary attached in front of it. That dictionary specifies the name, version, revision, and many other fields.

    There are basically two types of RPM packages: source and binary. Binary ones ar ethe products of builds. Source ones describe how to build, and thus they are the ones that interest us.

    A source RPM package has in its archive a spec file, sources (one or more) and patches (zero or more). The spec includes instructions how to build a binary package.

    So if you don’t have any patches, the one thing you need to maintain is ths spec file. Everything else (including the source tarball) could be automated using the standard RPM build toolchain. It would also be nice if you could verify the signature on the tarball[0].

    I personally prefer git-buildpackage-rpm that allows keeping the
    “tarballs” in git. You can either use tags directly to get tarballs from, or use pristine tar to store the delta between a tarball and a tag. But right now this is not a standard tool on CentOS systems, and you’ll have to install it on your own[1].

    The standard RPM+Git toolchain in Fedora seems to be fedpkg[2], but I
    think it would take quite some tweaking to make it work with your own seperate tarball repository. I don’t think it is useful for your case, but maybe someone more familiar than me can give an answer.

    If you really want to avoid conaminating the build system with all of those packages, do a chroot build inside mock (supported by the above two, or directly). A bit slower, and a longer debugging cycle, but keeps your system clean. It has support for caching downloaded packages and such.

    So in short, one proposed method:

    1. Install git-buildpackage-rpm
    2. Clone the package asterisk
    3. Create a branch called, say, packaging, with:
    debian/gbp.conf # Why Debian. that’s the way it is

    cat < debian/gbp.conf
    packaging-branch = packaging upstream-branch = master upstream-tag = ‘%(version)s’
    packaging-dir = rpm EOF

    4. Run:

    gbp buildpackage-rpm -ba # or also: –git-mock –git-dist=epel-7

    If you use mock, mock pulls all build-dependencies on its own. If you don’t, then you should probably use yum-builddep (from package eyum-utils. But I never tried it).

    Oh, and what if you just want rpm for getting the build dependencies installed and for running ./configure, ‘make’ (and menuselect) with the right magical arguments, and then you’ll run ‘make install’ on your own?

    Use -bc instead of -ba / -bb. You’ll end up with a built source tree. su[do] make install, and you’re done.

    [0] On Debian uscan only aquired this ability relatively recently. When I wrote a similar script a decade ago[4] I just verified the md5
    checksum to verify that I can safely avoid re-downloading.

    [1] RPM support is already mostly merged to the main git-buildpackage project: . Some extra features may be available in

    [2] See


  • Off-topic:

    From the build script:

    # build Asterisk
    ./configure –libdir=/usr/lib64
    cd $TARGET_DIR/$ASTVERSION/menuselect
    make menuselect
    make menuselect-tree

    ./menuselect/menuselect \

    #[snip menuselect parameters]

    # we want mp3’s


    (This is not intended to criticise Lenz)

    All of this magic (specifically the bits before the menuselect) is needed for a proper build?

    * Why is an explicit libdir packameter needed? What break if it is not
    * Why is there a need to build menuselect manually? What about ‘make
    menuselect’? Do we need a Makefile target to build menuselect but not
    run it?

  • Hi All,

    Thanks to Tzafrir Cohen who described very well that why RPM is better then any other script and how easy to build one.

    However for those like me still enough lazy to collect dependencies or setup mock builder, I recommend Koji build system for them. Either one can host his/her own Koji server or can freely signup for Community Koji Build system being hosted by CentOS and Fedora

    After you have access to koji build system it is very simple and quick to make your own custom RPM for any target distribution and architecture of your choice!


    Nasir Iqbal

    ICTBroadcast – an Auto Dialer software for ITSP
    SMS, Fax and Voice broadcasting & Inbound / Outbound Campaigns