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"?
Description: PGP signature