tech-pkg archive

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

NetBSD base system sqlite woes

I am mostly paying attention to NetBSD 9.

Base system sqlite has multiple issues:

  - It is old (3.26.0 in netbsd-9 vs 3.39.4 in pkgsrc)  
  - Some features are not compiled in (e.g. rtree).
This messages treats base sqlite as fixed and discusses how pkgsrc
should treat it; discussion of whether and how to change base sqlite
should happen on tech-userlevel@.

I am finding that base sqlite is not good enough for:

  matrix-synapse: not-yet-committed update needs 3.27 and missing features
  gdal: needs rtree, so tests fail with pkgsrc package

and it seems likely there are other issues.  It feels like 'sqlite not
good enough' is often not detected at build time and can be hard to
diagnose at run time.

This is difficult because:

  1) sqlite has options and there is an upstream convention, AIUI, that
  many are default off (in the docs) but also that many should be on
  according to popular wisdom (and hence upstream depends on them).

  2) py-sqlite3 needs some version of sqlite, but really things that use
  py-sqlite3 need py-sqlite3 built with some good enough version of
  sqlite and with enough options.

Point 1 is hard because sqlite's pkg-config file doesn't define which
options were used.

Point 2 means that "version high enough" as a switch to use pkgsrc vs
native isn't workable because packages that would set that would then
need a different and maybe conflicting py-sqlite3 as the requirement
passes through py-sqlite3 to sqlite3.

A wrinkle is that sqlite3's has
  BUILDLINK_API_DEPENDS.sqlite3+= sqlite3>=3.0.8
  BUILDLINK_ABI_DEPENDS.sqlite3+= sqlite3>=3.38.2nb1
yet the base version is treated as acceptable.

Thus I am left with one approach that seems sane:

  Declare that for pkgsrc purposes, native sqlite3 is only acceptable if:
    A) it is >= 3.27
    B) it has rtree and other options upstreams expect (and which are

this means that should fail for NetBSD base sqlite3, for 9 on
both counts, and probably for 10 on only options.

I don't see this as a big deal because sqlite3 is small, only 4 MB on

I do not believe that PREFER_ is appropriate because base sqlite is not
ok, and if we did that we'd have to have declarations for versions and
options that are checked and cause build failures.  Maybe that's a good
idea anyway, but i think the real point is that pkgsrc should stop using
NetBSD base sqlite3.

So proposed steps, roughly:

  1) in sqlite3 buildlink, document the required options as they arise

  2) change sqlite3's buildlink3 to require >=3.27 for API

  3) change sqlite3's to reject NetBSD's sqlite3.  Add other
  rejects as they arise.

  4) maybe, change to reject all and allow on platforms known to
  have the options, on the theory that random native sqlite3 is
  probabbly not ok.

I don't really care about 3 vs 4.


If you don't like this, how would you solve "building matrix-synapse and
gdal without messing with mk.conf ends up with a package that uses a
sqlite3 that works"?

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index