FAQ
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
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

Search Discussions

  • Adam Kennedy at May 22, 2009 at 7:50 am
    The concern I had at the time of zero'ing that code out was that we
    were moving the code so quickly that there could be problems with
    linking to a local version that would obscure the more important
    issues around getting the library itself upgraded and working.

    That's also why I zero'ed it out, rather than deleting it entirely.

    If you guys want to patch that one line to enable it again and see if
    you can get local library support working again with the overhauled
    code, you are welcome to do so, and I encourage it.

    Adam K

    2009/5/22 Jonathan Yu <jonathan.i.yu@gmail.com>:
    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
    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@lists.scsys.co.uk
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
  • Kenichi Ishigaki at May 22, 2009 at 10:20 am
    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.

    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).

    Kenichi

    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
    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@lists.scsys.co.uk
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
  • Jonathan Yu at May 22, 2009 at 1:02 pm
    Hi:

    Thanks for your prompt response and consideration.
    On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki 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 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
    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@lists.scsys.co.uk
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite

    _______________________________________________
    DBD-SQLite mailing list
    DBD-SQLite@lists.scsys.co.uk
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
  • Darren Duncan at May 22, 2009 at 8:06 pm

    Jonathan Yu wrote:
    On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki wrote:
    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.
    Jonathan,

    The core SQLite team via sqlite.org is very responsive to bug reports and does
    fix them in a reasonable timeframe, so the best thing that Debian can do is to
    work with them to fix bugs and to only release versions of SQLite that match
    core versions. Of course, if you continue to write patches also and send those
    upstream with your bug reports, that would be even faster.

    Or if you're already at the savvyness of writing patches, then someone on your
    team should apply to Richard Hipp to get a commit bit on the sqlite repository
    and apply your patches directly, so then there's no need to wait for anyone else
    to do something but your fixes are still official. Note that to get this commit
    bit you'll need to submit a signed form (see sqlite.org) to Richard Hipp stating
    that you grant your contributions to the public domain.

    On the side of DBD::SQLite, I have been quite prompt in updating the bundled
    copy of the sqlite library whenever a new release is made. Already I updated it
    to first 3.6.14 and then 3.6.14.1 within hours of those coming out.

    Adam, do you notice when the bundled sqlite library is updated in DBD::SQLite
    version control and if so do you think that it is fair to release at least a _N
    on CPAN when that happens? You hadn't so far so I wasn't sure.

    -- Darren Duncan
  • Don Armstrong at May 23, 2009 at 3:14 am

    On Fri, 22 May 2009, Darren Duncan wrote:
    The core SQLite team via sqlite.org is very responsive to bug
    reports and does fix them in a reasonable timeframe, so the best
    thing that Debian can do is to work with them to fix bugs and to
    only release versions of SQLite that match core versions.
    This is Debian's goal for all packages. However, even with the best
    possible communication with a responsive upstream, Debian often ends
    up distributing versions which include patches that fix bugs which are
    fixed in as-of-yet unreleased versions of upstream code or,
    alternatively, including security fixes that are present in an
    upstream release, but need to be backported to the (possibly outdated)
    version Debian is distributing in stable.[1]

    To avoid this extra effort (or worse, to be unaware of the need for
    it) convenience copies of libraries should not be used in Debian (to
    the extent possible[2]), hopefully through the use of
    upstream-supported compilation options. [The option to use a system
    library can of course be disabled by default.]


    Don Armstrong

    1: For those not familiar; our stable release remains static over its
    lifetime, with the primary exception of changes to fix security issues
    (and fairly rarely, major bugs which weren't caught before the
    release.)

    2: In the cases where it's not possible, the Debian Security Team
    needs to be made aware of this fact, and the maintainers of packages
    with convenince copies need to track bugs in the package(s) of which
    they use convenience copies.
    --
    But if, after all, we are on the wrong track, what then? Only
    dissapointed human hopes, nothing more. And even if we perish, what
    will it matter in the endless cycles of eternity?
    -- Fridtjof Nansen _Farthest North_ p152

    http://www.donarmstrong.com http://rzlab.ucr.edu
  • Adam Kennedy at May 25, 2009 at 7:35 am
    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.

    Adam K

    2009/5/22 Jonathan Yu <jonathan.i.yu@gmail.com>:
    Hi:

    On Fri, May 22, 2009 at 6:20 AM, Kenichi Ishigaki 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.
  • Jonathan Yu at May 25, 2009 at 2:39 pm
    Adam:

    On Mon, May 25, 2009 at 3:35 AM, Adam Kennedy
    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 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.
  • Adam Kennedy at May 26, 2009 at 2:35 am
    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@gmail.com>:
    Adam:

    On Mon, May 25, 2009 at 3:35 AM, Adam Kennedy
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbd-sqlite @
postedMay 22, '09 at 2:08a
activeMay 26, '09 at 2:35a
posts9
users5
websiteshadowcat.co.uk

People

Translate

site design / logo © 2021 Grokbase