[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Adam:

On Mon, May 25, 2009 at 3:35 AM, Adam Kennedy
<adamkennedybackup@gmail.com> wrote:
> As I noted before, there's a good reason I just zero'ed the code out.
>
> If you guys want to apply a local patch to false -> true that block,
> I'm ok with that. Debian are hardly the worst offenders when it comes
> to patches and linking things in.
>
> To enable it again more generally, I'd like to see some more strict
> tests that do similar things to DBIx::Class, tests that the embedded
> version will always pass, but that validate the the system-linked
> version is "good enough" for us to use.
>
> A lack of strictness in validating the system SQLite was what
> previously caused us problems.
>
> If we can add the quality of validation we need to "protect" the
> module, then we can re-enable it by default again.
I would agree with Kenichi Ishigaki that I'm not totally sure of the
merits of *defaulting* to the system-installed sqlite. On the one
hand, if DBD::SQLite ever gets out-of-sync with the current sqlite
version, then there could be a newer sqlite on the machine, and we'd
like to prefer that by default. However, currently, under your
maintainership, I don't think this is likely to happen, or likely to
be significant.

On the other hand, what we would really benefit from is simply being
able to set that variable, even if it defaults to the embedded sqlite
first. I think the assumption that on most systems, the included
sqlite will be the newest version is a fair assumption to make.

Clearly it would also help to have some diagnostics to ensure that
someone isn't trying to use an older version of sqlite
(system-installed) than DBD::SQLite is capable of; or older than the
one embedded in the package. I'm not sure if there is an appropriate
use case for either of these, since those needing older versions of
SQLite for whatever reason can simply install an older version of
DBD::SQLite or ::Amalgamation.

Obviously it does need more testing, and we'd be happy to put in some
work there.

Thanks for your candour. What I've resolved to do for now is test if
using the system-installed SQLite will cause issues for us on the
Debian side, and making appropriate patches. Of course I'll submit
them upstream once we've had them tested :-)

Cheers,

Jonathan
>
> Adam K
>
> 2009/5/22 Jonathan Yu <jonathan.i.yu@gmail.com>:
>> Hi:
>>
>> On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki <kishigaki@gmail.com> wrote:
>> 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.
>


Reply to: