Porting and packaging

One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging.

I've recently become enamoured of COPRs (Cool Other Package Repos). This is some Fedora infrastructure that makes it easy for anyone to build binary RPMs for various architectures and versions of Fedora and EPEL, and easy for end users to install them. EPEL, by the way, is the “extra packages for enterprise linux” system, which you already have installed on CentOS / RHEL unless you're very strange.

According to my current understanding, a COPR is pretty much equivalent to a PPA (Private Package Archive) in the Ubuntu world. I am primarily a Fedora guy, although professionally I support Debian, Ubuntu, and CentOS systems. I'll have a bash at creating a PPA soon, but for now I'm concentrating on COPR.

It didn't take me long to write an RPM .spec file. (Heck, I once had a consultancy gig writing RPMs for money!) It worked just fine on my primary development platform, currently Fedora-24 on x86_64. Nor did it take long to create a COPR account and upload my source RPM to the build system. Then I ticked the boxes to choose a bunch of the available versions and architectures, and went to make a coffee.

Imagine my surprise to return to a long list of failures! It took a fair while to fix them all, but the good news is that pacc is in fact pretty portable. The failures were of three sorts.

1. Not quite a failure, but on a modern 32-bit system, most of the trace lines in a pacc-generated file (and there are over 2000 in pacc.c) produced a warning. They need to print a size_t value, and I had used %ld. It turns out that C99 added the z modifier for just this case, so all the formats were replaced with %zu.
2. There were a few bugs in the test suite; use of uninitialized values, writing past end of buffer, that sort of thing. These had worked by coincidence on my development system, but caused failures on the ppc architecture.
3. Some of the test cases involve errors produced by the C compiler. These have changed between different versions of gcc (I'm not currently pretending that you can build pacc with any other C compiler). For example, reporting the column where the error occurred, as well as the line, is a relatively recent innovation. The test suite is now more flexible about what it will accept.

With some tweaking, I managed to get pacc building, and passing its test suite, on the three current releases of Fedora (22 - 24), three architectures each (i386, x86_64, and ppc64le). And 2 versions of EPEL: EPEL 6 comes in i386 and x86_64 flavours; under the fairly recent EPEL 7, only x86_64 is supported.

I abandoned trying to get it going under EPEL 5. I forget exactly what the problems were, but it looked like it was going to be pretty tedious, and EPEL 5 is in the last year of “security fixes only” support. Nobody is going to be developing new software for it. Similarly, the Fedora 22 ppc build failed in ways that looked uninteresting, and F22 reached end-of-life a couple of weeks ago.

Anyway, the upshot of all this, is that if you run Fedora, you can run these commands:

dnf copr enable tobygoodwin/pacc
dnf install pacc

And that's it! Pacc is now installed as /usr/bin/pacc, and you can read the documentation locally with info pacc.

For CentOS and RHEL, you can enable the COPR with yum copr, or download an appropriate .repo file from the pacc copr which has all the links and details you need.

Hopefully this makes pacc more readily available to some of the people who might be interested in using it. Perhaps more importantly, the exercise has made pacc, and particularly its test suite, considerably more portable.

If you are not covered by the COPR, then you will be interested in this new source release.