1) I'm afraid Alien:: namespaces are not for the libraries
like sqlite and zlib that can be easily embedded without
creating extra .so/.dll files. See Compress::Raw::Zlib for

2) It may be nice to use a system-installed library (maybe
with a selection of patches applied), but if it changes
behaviors of DBD::SQLite, it'll annoy people who build
their software (like O/R mappers) upon DBD::SQLite.
See DBIx::Class's Makefile.PL, which tests if DBD::SQLite
is not built with problematic versions of sqlite library,
as it may cause unexpected errors, and the errors are most
likely to be reported to them (not us, nor the sqlite team).

So, it's totally ok for you to apply a patch to use a local
(customized) library you have to create a binary distribution,
but I'm not inclined to agree to use always a local library
if available (as DBD::SQLite did before).

Besides, debian is not a minor player. I think it's better
to send a patch to the sqlite team, which in turn we'll
include later when a new version of the library is out
(than to apply a local patch that might be lost or forgotten
to be applied to other libraries like DBD::SQLite).


On Thu, 21 May 2009 22:08:43 -0400, Jonathan Yu wrote:

Hi all:

In Debian we maintain a package for the sqlite3 libraries. We also
maintain a package for DBD::SQLite, which includes a bundled version
of sqlite3.

Judging by the Makefile.PL, there are ways to force the module to use
the system SQLite, but it has been disabled:

# 2005/6/19, by rjray@blackperl.com
# 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.

# 2009/04/02
# But why do we need to use an older, system-installed library?
# Let's always use the bundled one. -- ISHIGAKI
# 2009/04/03
# For the moment, while we're fixing things, this is reasonable.
# However, logic in the form "I lack knowledge, thereforce lets do
# it this way" is not a sufficiently robust decision making process.
# Let's find out the full story first, so we can make an informed
# decision to whether to do this. -- ADAMK
From your standpoint as DBD::SQLite developers, it makes sense - "the
system sqlite can be older than the one we're designed to work with;
how can we tell otherwise?" From a Perl developer standpoint, I think
the best place for an embedded sqlite installation is in an Alien
package. The idea with those is that you'd simply depend on
Alien::SQLite, and Alien::SQLite would install the package if

However, in Debian, we keep track of system packages such as sqlite3
and can guarantee that it is the appropriate version for use with the
bindings provided in DBD::SQLite. Ideally, those command-line
parameters above would be fantastic for us, in order to use the system
SQLite instead of the local version only.

This is because we might have patches in our sqlite3 package. If you
use the version bundled with DBD::SQLite, then obviously these patches
would be lost, which ultimately hurts our users.

So, for what it's worth, I'd just like to say that this would be a
great install feature for us, even as currently implemented (though
disabled with the whole if (0) surrounding it). I'm curious as to why
it was disabled in the first place; is it because the code for using a
system sqlite is insufficiently robust?

Thanks for any advice or suggestions you can offer. If there is a
better way to do this, I'd love to hear it.



DBD-SQLite mailing list

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 9 | next ›
Discussion Overview
groupdbd-sqlite @
postedMay 22, '09 at 2:08a
activeMay 26, '09 at 2:35a



site design / logo © 2021 Grokbase