[ Accidentally replied only to Josh, duplicating to list ]
On Fri, Jul 1, 2011 at 6:32 PM, Josh Cepek <josh.ce...@usa.net> wrote: > I was building the subversion 1.7.0-alpha2 pre-release in a CentOS 5.6 > environment and encountered an interesting problem with the new dependency > for python's sqlite support. > > CentOS seems to name the site python library 'sqlite' while the subversion > system expects to import 'sqlite3'. This causes the test to halt accordingly > on the first python test when the import fails. The "sqlite" package in CentOS/SL/RHEL/etc. is labeled "sqlite-3.x" and the package of development components, such as include filoes, "sqlite-devel-3.x" Have you installed those development components? What does "rpm -q sqlite-devel" say? And to avoid surprises like that, I urge you to grab the SRPM's from RPMforge or from RHEL 6 and compile them locally, just to make sure you have all the previously known dependencies before you even start. Then, when you're ready for production work, you can use "mock" or something like it to build your new RPM's in a pristine environment. (This is what I did, for years, pre-testing subversion updates to submit them to RPMforge.) I'm also going to suggest you look into Scientific Linux as your next RHEL based update: SL 6 has already been out for six months, and it's like jumping in a time machine to work with a code base that's 4 years newer. ext4 has also gotten stable, and can be a big performance improvement for large Subversion repositories. Do a clean build and start with ext4 filesystems: you won't be sorry. > I'm not sure if the solution is to have the distro packager of the > python-sqlite package update the site paths (or at least symlink sqlite3 -> > sqlite) or to patch the svntest library to handle this case. Both methods > worked as expected for me, and allowed the test suite to continue. Spec file dependencies are... interesting, and can be RHEL release specific. Look for the settings in the RPMforge versions of subversion based on the '%dist' settings. Since you're not working from an SRPM, take a look at the .spec files for their dependencies. The .spec files in swubversion itself are, unfortunately, unusable and need to be replaced with RPMforge's or RHEL's. Under *NO* circumstances should you use the rpm packaging structure in the subversion source code. It hasn't worked for years, and it replaces the software builder's.rpmmacros without warning. No build system should *ever* modify the rest of your build system without notice this way. > In the event we want to support this within the 1.7.x test suite, I've > attached a patch to svntest/__init__.py that adds an additional try clause > to import sqlite as sqlite3. I'm not sure if there are any historical > implications (read: a previously named sqlite library) to this patch. If the library components are actually named that, yeah, detecting them makes sense. Personally, I've given up on RHEL 5 based distributions. RHEL 6 based is such a massive leap forward that the older releases hardly seem worth the worth the effort: RHEL 6 came out over 3 years after RHEL 5, and RHEL 5 was already lagging behind when it was published. Don't burn your effort there. > If the Subversion devs view this as a completely upstream problem I may file > a bug there, but the chances of it getting fixed are pretty low since CentOS > just repackages what RHEL provides. RPMforge might be a better venue there. I used to publish Subversion update notes on that distribution.
