Bugzilla Bug 123285

I'm not entirely sure where the fault for this bug lies. I have a Web-based
application that uses Class::DBI, DBI, and SQLite. It works fine. If I upgrade
SQLite to 3.3.4, the application breaks, with errors of this form:

FOF::Feeds can't
SELECT f.uid,f.url,f.title,f.link,f.last_poll,f.desc,COUNT(i.uid) as
total_items
  FROM feeds AS f,items AS i
 WHERE f.uid=i.feed
 GROUP BY f.uid
 ORDER BY f.title
 ASC: DBD::SQLite::st execute failed: not an error(21) at dbdimp.c line 398
[for Statement "
SELECT f.uid,f.url,f.title,f.link,f.last_poll,f.desc,COUNT(i.uid) as
total_items
  FROM feeds AS f,items AS i
 WHERE f.uid=i.feed
 GROUP BY f.uid
 ORDER BY f.title
 ASC"] at /usr/lib/perl5/vendor_perl/5.8.8/DBIx/ContextualFetch.pm line
52.
 at /var/www/localhost/htdocs/FOF/feeds.cgi line 29

Reverting to SQLite 3.2.7-r1 fixes the problem.

I have tried recompiling DBD::SQLite, DBI, Class::DBI, and
DBIx::ContextualFetch against the new SQLite, but that does not fix the
problem. 

Googling the 'dbdimp.c' part of the error turns up a patch against DBD::SQLite
1.0.9, but I haven't gotten to the point of trying that out yet. 

Here's `emerge --info`:

Portage 2.1_pre4-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.6-r2,
2.6.15-gentoo-r4 i686)
=================================================================
System uname: 2.6.15-gentoo-r4 i686 AMD Duron(tm) processor
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon -mtune=athlon -O3 -fomit-frame-pointer -ftracer
-fprefetch-loop-arrays -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon -mtune=athlon -O3 -fomit-frame-pointer -ftracer
-fprefetch-loop-arrays -pipe -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/
ftp://ftp.ndlug.nd.edu/pub/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo
http://gentoo.blueyonder.co.uk
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 pam elibc_glibc kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LINGUAS

Added perl as it's their package

I think right now the problem is that the bundled version of sqlite that comes
in dbd-sqlite is older than what you have on your system. sqlite (the app) is
backwards compatible, but dbd-sqlite is still 'stuck' at 3.2.7. The maintainers
of sqlite (the db :) have asked matt to update as of last week:
http://rt.cpan.org/Public/Bug/Display.html?id=17571

(In reply to comment #2)
> I think right now the problem is that the bundled version of sqlite that comes
> in dbd-sqlite is older than what you have on your system. sqlite (the app) is
> backwards compatible, but dbd-sqlite is still 'stuck' at 3.2.7. The maintainers
> of sqlite (the db :) have asked matt to update as of last week:
> http://rt.cpan.org/Public/Bug/Display.html?id=17571

I'm not sure I understand. The database in question was created with
DBD::SQLite, and is only accessed via DBD::SQLite. I've got the 'sqlite' ebuild
installed in case I need to do debugging, but I can reproduce this problem
independently of the command-line 'sqlite' tool. That's part of what makes this
so confusing -- given that DBD::SQLite _has_ the embedded SQLite, I'm not sure
why the "stand-alone" SQLite ebuild being installed has any effect at all.

My understanding (possible wrong, I admit, but this is the impression i've been
led to so far) is that the bundled sqlite is only invoked if you don't have a
copy on your system. Since you in fact do have a copy on your system,
DBD::SQLite is using the libraries contained there rather than anything it
might have been bundled with -and hence the discprepancy, bad mojo, and all
around breakage. I suspect upstream for DBD::SQLite will be correcting this
shortly, soon as he gets to his rt bugs.

Just an update: I bought an x86_64 machine. The problem still happens there,
and it still exists. 8^/=

(In reply to comment #5)
> Just an update: I bought an x86_64 machine. The problem still happens there,
> and it still exists. 8^/=
> 


The original, actually filed bug, was that after upgrading from 3.2.7 of sqlite
to 3.3.X of sqlite, dbd::sqlite failed to work. That is resolved as upstream,
again see the posted link to rt on cpan. if you build a new box and put on it
3.3.x of sqlite, dbd::sqlite is still going to have the same problem.

Do ~dev-perl/DBD-SQLite-1.12 and ~dev-db/sqlite-3.3.5 work fine together?

,--Changelog
| 1.12
|       - Brought up to date with SQLite 3.3.5
'--


| My understanding (possible wrong, I admit, but this is the impression i've
been
| led to so far) is that the bundled sqlite is only invoked if you don't have a
| copy on your system.

Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it
should be in the dependencies.

,--- Makefile.PL
# Determine if we are going to use the provided SQLite code, or an already-
# installed copy. To this end, look for two command-line parameters:
#
#    USE_LOCAL_SQLITE -- If non-false, force use of the installed version
#    SQLITE_LOCATION  -- If passed, look for headers and libs under this root
#
# In absense of either of those, expect SQLite 3.X.X libs and headers in the
# common places known to Perl or the C compiler.
'---

(In reply to comment #7)
> Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it
> should be in the dependencies.

It's not a dependancy though. It's optional at best to have a copy of sqlite on
your box before installing the perl module - its not a requirement, and so not
listed in the deps.

(In reply to comment #8)
> (In reply to comment #796)
> > Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it
> > should be in the dependencies.
> 
> It's not a dependancy though. It's optional at best to have a copy of sqlite on
> your box before installing the perl module - its not a requirement, and so not
> listed in the deps.

If sqlite is present it is linked in and it becomes a dependency. DBD::SQLite
will break if sqlite will be removed afterwards. So sqlite becomes a dependency
of DBD::SQLite.
I see two possible ways here: always use the included code or always require
sqlite being installed.

Perl team, how do you all suggest we proceed on this?

I lean against making sqlite a dep since it isn't (weak, I know). Even making
it a dep doesn't solve the issues presented by tove in #9 - sqlite can still be
upgraded or removed regardless of dbd-sqlite.

That said, we do have an option or two in the module itself (that i really
don't remember existing before). Chiefly we can either:
#    USE_LOCAL_SQLITE -- If non-false, force use of the installed version
#    SQLITE_LOCATION  -- If passed, look for headers and libs under this root

Personally, I prefer the former - keep the two kids apart, no dep breakage.
anyone against that?

ok, went with the internal only for now. i've done a tree scan and doing this
to the latest version of dbd-sqlite won't affect anything. We'll see how it
goes from here and readdress if need be.