Description of problem: perl-DBD-SQLite is currently using an internal copy of sqlite instead of the system-wide sqlite shared lib coming with the package "sqlite". This is advertised differently in the rpm description and has the disadvantage that bugfixes/security updates/... that get published via a new sqlite package don't affect code accessing sqlite databases from perl. Version-Release number of selected component (if applicable): 1.25-4.fc12 How reproducible: always Steps to Reproduce: 1. ldd /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so Actual results: linux-gate.so.1 => (0x00987000) libc.so.6 => /lib/libc.so.6 (0x00235000) /lib/ld-linux.so.2 (0x00213000) Expected results: linux-gate.so.1 => (0x00987000) libc.so.6 => /lib/libc.so.6 (0x00235000) /lib/ld-linux.so.2 (0x00213000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (...)
This problem is present in the version targeted for FC13 too: perl-DBD-SQLite-1.27-2.fc13
The spec file has the following comments in it: # if sqlite >= 3.1.3 then # perl-DBD-SQLite uses the external library # else # perl-DBD-SQLite is self-contained (uses the sqlite local copy) but I'm not seeing it happen.
Created attachment 382984 [details] Patch to make DBD-SQLite use the system sqlite libs instead of the internel version This patch forces DBD::SQLite to use the system libs instead of relying on the internal version.
Hi Emmanuel, just took a look at this too, came up with the same patch, but you were faster ;) I can confirm that your patch fixes this. So it would be nice if it could be applied.
Nice patch ;-) Thanks, fixed as perl-DBD-SQLite-1.27-3.fc13