AWEL Custom RPM Packages for RHEL/CentOS 7

A project I am currently working on requires some Open Source Software that is not currently distributed with RHEL/CentOS 7 or the standard EPEL additions to RHEL/CentOS 7.

Specifically I needed a modern build of FFmpeg capable of transcoding video to and from H.264/MPEG-4 AVC and I also would very much would like to develop now for the PHP 5.6.x stable branch so that there are not any porting issues when my project is finished and ready to market.

This necessitated the compilation of custom RPM packages so that I can start developing my code. I have decided to share them so others who are not quite as proficient with building RPM packages can benefit from them. Maybe it will help me build some good will.

(skip to setup)

Package Repositories

The packages I have built and will maintain as best I can are split into six categories:

With the exception of the GStreamer packages, the groups can be used independent of each other. The GStreamer packages are built against libraries from within the FFmpeg / Media repository.

Build Philosophy

I have been building RPM packages for a long time. The first time I was actually paid to write an RPM spec file was in 2000, I was the RPM build-master for the Silicon Valley company Unitek, or rather the Abriasoft spin-off company they were starting. Unitek wrote the paychecks.

Since that time I have learned a lot about RPM packaging and RPM packaging itself has changed quite a bit, for the better too.

Always Build In Mock-- When building an RPM package, it is easy for the package to accidentally link against software installed on the local system that it really should not link against. By always building packages in a clean chroot mock environment, these accidental linkings can be avoided. The package will only link against libraries in the mock build environment which is packages that are generally readily available to those installing the package through yum.
Avoid Conditionals-- This is a point of contention between me and many packagers. Many packagers like to maintain a single spec file that builds on every version of every distro. While it does seem appealing, it results in an RPM spec file that is often incorrect for a given need. For example, the GStreamer plugins RPM spec files in the Fedora world will disable certain plugins if building on RHEL/CentOS because the needed libraries are not in RHEL/CentOS but they fail to take into consideration that those libraries often are available in EPEL or may have been built and are available to the system. Then when rebuilding the Fedora src.rpm someone like me has to modify the spec file and remove the conditionals that say don't do this on RHEL. I find it much better to not use conditionals, and instead let the BuildRequires take care of letting someone know what build dependencies there are, they can comment out the optional BuildRequires for their specific version of their specific distro when building from your RPM spec file.
Pristine Source-- Something Red Hat / Fedora are infamous for, they will alter the source to remove code they believe may violate software patents. This is essentially creating a fork and it is wrong for them to do it in my opinion. They do not just avoid building the part of the source their lawyers feel are legally dangerous to build, they actually ship source that has pieces of code missing from it. They do this with php, they do this with GStreamer plugins, they do this with other packages as well. Upstream source should not be modified unless you call your fork something else, the source should be pristine. If you feel you can get into legal trouble for building something, then do not build that component of it. That is what configure switches are for, but do not remove the source. Source is free speech and I do not believe it is legally dangerous to ship source. I do however believe the source is sacred and in FLOSS, the upstream source should be shipped pristine.
RPMLint-- RPMLint is an extremely useful tool for finding packaging mistakes, including mistakes that are the fault of the upstream source, such as rpaths. Sometimes the errors found by RPMLint are bogus but for the most part, when they can be corrected they should be corrected.
Fedora Packaging Guidelines-- Even though I no longer create packages for the Fedora Project, the Fedora Packaging Guidelines are an excellent set of packaging guidelines. I defer to them often when making packaging decisions. For the most part, they are extremely well thought out and are an excellent standard to package to. Oh how I wish they had existed when I first started creating packages…
GPG Signed Packages-- When creating RPM packages, they should always be signed by a GPG key. This is how the RPM package manager knows that the packages have not been modified by a third party before installing them on your system. The GPG key that I use to sign all my packages for RHEL/CentOS 7: RPM-GPG-KEY-AWEL7.

Always feel free to contact if you have any packaging issues or questions.

Repository Setup

All of my package repositories assume that you have the EPEL packages available to you. On CentOS 7, open a root shell and type the command:
yum install epel-release
and you should be good to go. RHEL users may have to download the release package and install it manually from http://download.fedoraproject.org/pub/epel/7/x86_64/repoview/epel-release.html.

PHP / FFmpeg / Misc

These three repositories are the first three I created and I think are the three that most users are most likely to desire packages from. To use those repositories, first you must manually install the awel-release package. That will install the yum repository file and the GPG key. It will not however enable the package repositories, you need to decide which of them you want and enable them using a text editor.

To enable a repository, edit the file /etc/yum.repos.d/awel.repo and edit the configuration you wish to enable. For example, to enable the media (FFmpeg and friends) repository, the default configuration looks like this:

[awel-media]
name=AWEL CLI Multimedia packages for RHEL/CentOS 7 - $basearch
baseurl=http://awel.domblogger.net/7/media/$basearch
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AWEL7

Change the line that says enabled=0 to enabled=1 so it will now look like this:

[awel-media]
name=AWEL CLI Multimedia packages for RHEL/CentOS 7 - $basearch
baseurl=http://awel.domblogger.net/7/media/$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AWEL7

Now you can use yum to install software programs and libraries from the media repository, e.g.

yum install ffmpeg

Once you have enabled the repositories you want, any updates will also automatically be pulled down whenever you update the operating system. Linux has had the right concept for decades, it is too bad OS X and Windows can't figure it out…

Special PHP Note

If you enable my PHP repository, then I highly recommend you specifically disable PHP in the RHEL/CentOS Base and Updates repository and in the EPEL repository. You can do this by adding the line:

exclude=php*

to their yum configuration.

GStreamer

The GStreamer package repository requires libraries from the FFmpeg/media package repository. First enable that repository as described above. Then issue the command:

yum install awel-gstreamer-release

Once that is installed, it is enabled. To update your GStreamer, issue the commands:

yum clean all && yum update

Crypto-Currencies

If all you are after is bitcoin, do not bother using my repository. Just use the repository at Ring Liberty. My bitcoin packages are just rebuilds of his.

However if you are interested in Namecoin, QuarkCoin, or some of the alternative bitcoin clients that I hope to soon be packaging then you will want to install my awel-crypto-release package.

Special Packages

These are packages that are not available through yum. Most of them are nosrc.rpm files that you can use to create a binary RPM file for commercial software that is not distributable as open-source software. It can still be advantageous to create RPM files for them.

I also am experimenting with meta-packages to help systems that have TeXLive installed the TeXLive way avoid the un-necessary bloat of RHEL/CentOS packaging of TeXLive. It is not yet a finished project.

Support

I do not offer official support but I do try to help people when I can. Eventually there may be a discussion list, but for now you can just e-mail me, remove the #s and @ the [at] and . the <dot> : alice#wonder[at]shasta#herps<dot>org