pg_duckdb: ship libduckdb.so once as a shared pgedge-libduckdb package - #79
pg_duckdb: ship libduckdb.so once as a shared pgedge-libduckdb package#79maqeel75 wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
Included review availability: 1 review is currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. 📝 WalkthroughWalkthroughThe packaging changes create a shared ChangesShared DuckDB Engine Packaging
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to The PR consolidates the shared DuckDB library into a version-pinned package while keeping per-major PostgreSQL packages focused on the extension; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Up to standards ✅🟢 Issues
|
Summary
libduckdb.sois DuckDB itself, built from pg_duckdb'sthird_party/duckdbsubmodule and shipped by every per-major package. Nothing in it is PostgreSQL-specific (.text/.rodataare bit-identical across PG 16/17/18), so all three packagescarried the same binary with the same build-id — and each claimed
/usr/lib/.build-id/<xx>/<hash>pointing at its own PG libdir. rpm's transaction test and dpkg both reject that, so installing pg16+pg17+pg18 side by side failed:file /usr/lib/.build-id/e1/357265... conflicts between attempted installs of
pgedge-pg-duckdb_16 and pgedge-pg-duckdb_17
It only appeared to work on el10/Ubuntu, where an accidental per-major RUNPATH changed the build-id.
The engine now ships once as
pgedge-libduckdbinto/usr/lib/pgedge/coldfront/libduckdb, alongside the duckdb extensions.pg_duckdb.sofinds it via an RPATH appended toSHLIB_LINKat build time (no symlinks, nopatchelf), and theper-major packages contain only the extension.
release.yml'spg_versions, so it advances on its own.= 1.5.4/>= 1.5.4~, << 1.5.5~), so one major can be rebuilt at a higher buildnum while 1.5.4 never pairs with 1.5.5 across the C++ ABI.bogus date in %changelogweekdays in three specs.Verified in containers on almalinux:9 and debian:trixie with real spec/
debian/rulesand stubbed compile, against the live release repo:main's packaging reproduces the conflict, this branch installs all majors + engine cleanly, andlddresolves the engine through the RPATH. Real published binaries confirm the RUNPATH is present on both distros.