[DBD-SQLite] Using System SQLite Instead of Bundled Version

Jonathan Yu jonathan.i.yu at gmail.com
Fri May 22 13:02:21 GMT 2009


Hi:

Thanks for your prompt response and consideration.

On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki <kishigaki at gmail.com> wrote:
> Hi.
>
> 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
> example.
Yeah, I really don't have any idea there. It was just a thought.
>
> 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).
I agree with you here. However, what I was asking for is simply to
re-enable the behaviour before, where a variable/parameter to
Makefile.PL gets to decide which to do. Definitely, other systems may
not have an up-to-date system sqlite installation and cannot be
guaranteed thus, so I do think that your argument to remove that
functionality is valid. On the other hand, I don't see the harm in
defaulting to the embedded version but also allowing people to choose
to use the system-installed version if they wish, hopefully knowing
the risks of doing so.
>
> 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).
Well, when we write patches, we do so to the benefit of our users. We
usually forward the bug report upstream on behalf of our users, who
simply use bugs.debian.org as the single point to file a bug. However,
if we can't get the upstream to fix it in a reasonable timeframe, we
result to patching it locally and forwarding that patch upstream too,
in the hope that they will apply it.

This is essentially what I'd suggest for point (2).

However, I feel it to be a small change, simply allowing local
installations of sqlite to be used, rather than defaulting to it. Then
it won't break any behaviour and we can easily use it within Debian,
since we control what flags are passed to Makefile.PL during the
package build process.
>
> Kenichi
>
>
> On Thu, 21 May 2009 22:08:43 -0400, Jonathan Yu <jonathan.i.yu at gmail.com> 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 at 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
>>necessary.
>>
>>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.
>>
>>Cheers,
>>
>>Jonathan
>>
>>_______________________________________________
>>DBD-SQLite mailing list
>>DBD-SQLite at lists.scsys.co.uk
>>http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>
>
> _______________________________________________
> DBD-SQLite mailing list
> DBD-SQLite at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>



More information about the DBD-SQLite mailing list