| Summary: | SQLite upgrade breaks DBD::SQLite | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | john s j anderson <jacobs> |
| Component: | [OLD] Development | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arj, perl, tove |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
john s j anderson
2006-02-18 07:52:09 UTC
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. |
