[asterisk-users] Pet project: one step Asterisk compile on Centos 7

[Tzafrir Cohen]

On Tue, Jun 14, 2016 at 06:22:05PM +0200, Lenz Emilitri wrote:
> 2016-06-14 17:44 GMT+02:00 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
> >
> > 1. Asterisk basically has such a script inside.
> 
> It is - as you say - inside. This is outside and does the download for you.
> 
> > 2. Asterisk has an RPM package. An RPM package is exactly a reproducible
> > build (listing dependecies, and such).
> 
> 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.
> 
> > 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.
> 
> 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:
   rpm/asterisk.spec
   debian/gbp.conf # Why Debian. that's the way it is

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

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com