[ Accidentally replied only to Josh, duplicating to list ]
On Fri, Jul 1, 2011 at 6:32 PM, Josh Cepek <josh.cepek_at_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.
Received on 2011-07-02 15:02:09 CEST