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

[Adam Kennedy]

I'd agree we want to default to embedded and allow system linking only
with some environment variable.

But I'd also like to see the issue of testing for version-agnostic
problems like bad compilation options addressed (where these problems
are detectable by us).

If we have that level of testing in place, then there's no simple way
for people to hurt themselves trying to just "do the right thing".

If they really do know better than us, and want a very specific
alternate version or alternate settings, they'll have to not only set
an environment variable, but they'll also have to force the tests.

I'm assuming that the most legitimate cases like Debian et al will
still pass whatever tests we add. I'm mostly thinking in terms of the
old saying a couple of us in the CPAN toolchain group use to have
regarding RedHat's Perl team.

"For every mechanism that exists in Makefile.PL that allows the user
to make a choice, RedHat will pick the worst option on behalf of their
entire userbase".

(This is less true since they picked up their game in the latest
Fedoras, but has been a good use case of a long time)

If we can prevent the naive from hurting themselves, that's about the
level of protection I want to see. The elites can already look after
themselves.

Adam K

2009/5/26 Jonathan Yu <jonathan.i.yu at gmail.com>:
> Adam:
>
> On Mon, May 25, 2009 at 3:35 AM, Adam Kennedy
> <adamkennedybackup at 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 at gmail.com>:
>>> Hi:
>>>
>>> On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki <kishigaki at 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.
>>
>