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 buildlink3.mk 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
normal)
this means that builtin.mk 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
amd64.
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 builtin.mk to reject NetBSD's sqlite3. Add other
rejects as they arise.
4) maybe, change builtin.mk 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.
Thoughts?
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