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

  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. http://packages.asterisk.org/CentOS/

  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!

  l.

• 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:
  rpm/asterisk.spec
  debian/gbp.conf # Why Debian. that’s the way it is

  cat <debian/gbp.conf
  [DEFAULT]
  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: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ . Some extra features may be available in https://github.com/marquiz/git-buildpackage-rpm

  [2] See https://fedoraproject.org/wiki/Package_maintenance_guide?rd=Using_Fedora_GIT

  [4] http://updates.xorcom.com/astribank/bristuff/1.4/INSTALL.html

• Off-topic:

  From the build script:

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

  ./menuselect/menuselect \

  #[snip menuselect parameters]

  # we want mp3’s
  ./contrib/scripts/get_mp3_source.sh

  make

  (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
  passed?
  * 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!

  Regards

  Nasir Iqbal

  ICTBroadcast – an Auto Dialer software for ITSP
  <https://www.ictbroadcast.com/how-become-internet-telephony-service-provider-itsp-using-ictbroadcast-sp-edition>
  SMS, Fax and Voice broadcasting & Inbound / Outbound Campaigns http://www.ictbroadcast.com/