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.
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.
Last updated: 2016-08-03 21:31:34 UTC
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. Read More...
Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...