I want to openly distribute to the interwebs various pieces of software, some that I’ve already developed, and some that I am in the process of developing. And I’d like to grow a developer and user community around this software on this web site. I don’t want to use SourceForge, Google Code Projects, and similar services. In short, I want the code and support services to be hosted on my server, because it will help bring readers and traffic to my humble weblog.
Easy. Yeah, right! I spent most of the day and night Wednesday, and half the day today Thursday, fighting with my server. All this because of the poor technology choices of my hosting provider.
Pjtrix and the other domains I run, are served from a GoDaddy virtual private host. GoDaddy uses Virtuozo, a commercial Linux virtual private server (VPS) implementation, and the Fedora Core Linux distribution. GoDaddy upgraded their VPS service last year to Fedora Core 2 (FC2).
Unfortunately, while FC2 is great and all as Linux implementations go, it is no longer maintained. The Fedora project calls this end-of-life, or EOL. After EOL, there was a brief time when FC2 was maintained by the Fedora Legacy community. But they too stopped producing updates for FC2, about a year ago. You could say it went from EOL to SOL (sorry, couldn’t resist!)
The Fedora Legacy package repositories for FC2 have an old version of Subversion that is not supported by Trac, and Trac itself is not among the FC2 packages. So as the good open source maven I am, I tried to install Trac and Subversion directly from the latest source. But I kept coming to a dead end with two big catch-22 issues.
I ran into the first issue when trying to configure the Subversion code, before attempting to compile it (the proverbial first step in building an open source package for Unix systems.) The configure script complained the GNU C Standard library (gnuclib) on my system was too old and not supported by Subversion. Since there was nothing else available, I tried to upgrade the gnuclib using the out-of-date Fedora Legacy repository, hoping this would be good enough.
But when I attempted this, several FC2 packages complained that the library I wanted to install was not the one they needed. They wanted *only* the gnuclib which was already installed, a library apparently provided by Virtuozo.
This is the second issue, and you can see where this is going, I hope.
It seems Virtuozo is implemented as a special virtualizing Linux kernel with a specially crafted gnuclib. And this means GoDaddy doesn’t run a plain vanilla FC2 on its VPS servers. Instead, they run a Virtuozo-provided, specially crafted modification of FC2 that is practically impossible to update, even if there were up-to-date packages available!
The actual solution I ended up implementing was simple, but before I found it, I did spend nearly eighteen hours out of the last forty-eight, spinning my wheels and trying different things. I tried mucking with the Subversion code, fooling it into accepting the Virtuozo-provided gnuclib. But this produced a flaky executable (I guess that’s why that version of gnuclib is unsupported.)
I tried hacking Subversion and Trac RPMs from FC4, but while they installed OK, they didn’t run because of shared library linking issues. I tried installing a separate C Standard library (newlib) somewhere else on my server, and fooling Subversion into using that library. But I couldn’t get this to work.
I tried trolling around RPM and .deb repositories, trying to install every Subversion package I found. None of them wanted to install.
In the end, I found the RPMForge third-party repository, with both up-to-date Trac and Subversion packages for FC2. And they were built in such a way not to conflict with Virtuozo and its crazy hard-coded package version numbering. And so far, they seem to run decently.
Hopefully there will be no more surprises, and I can get started putting my projects up in the repository over the next few days. If I hit any more snags, I may just end up putting my code up somewhere else, though.