Bring libpq into line with `pkgs/servers/sql/postgresql/generic.nix`,
which already lets consumers retain the static archives alongside the
shared libraries by setting `dontDisableStatic = true`. libpq's
`postInstall` previously deleted every `.a` from `$dev/lib`
unconditionally on non-static builds; consumers that need both the
shared library and a native-ELF static archive had no in-tree way to
keep them.
The default behaviour is preserved: when `dontDisableStatic` is unset
or `false`, the `.a` files are still removed, and the resulting
`postInstall` string is identical to the previous one, so the
derivation hash for existing consumers does not change.
This has worked before - but only accidentally so. It worked once we
enabled `structuredAttrs`, but there was a bug in the stdenv adapter for
`pkgsStatic`, which made it ineffective when using `structuredAttrs`.
With the bug fixed, libpq was broken again. This time, we fix it by
entirely disabling the build of shared libraries in PG's Makefiles for
the static case. No shared libraries - no problem.
This allows `postgresql.withPackages` to easily override the paths to
the default and man outputs for `pg_config`. It avoids all
`buildEnv`-dev-output hackery, which it didn't properly support, and
separates the logic cleanly.
This can be observed when building
haskellPackages.postgresql-libpq-pkgconfig. This is currently pinned to
postgresql_16 in pkgsStatic, but when unpinning it, it will fail with
the mentioned error on master. With this fix, it successfully builds
with postgresql_17 / libpq.
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
We had set the "stamped" commit in #382282, a few days before the tags
appeared. The tags are now there, so we can replace them. The hashes
stay the same.
This allows us to fetch newer releases a few days before they are
officially released and the tarballs have been pushed.
The regular release cycle is like this:
- Sunday, the release notes are committed.
- Monday, the version is "stamped", i.e. the version bump committed.
- Thursday, the release is made.
There are not going to be any changes from Monday on, so we can kick off
our builds at that time already - they still need time to hit unstable
anyway.
With the same reasoning as for postgresql's pg_config, we need to make
adjustments to libpq's variant. Otherwise it would not return the
correct LIBDIR, pointing at the -dev output instead of -out.
