postgresql: replace pg_config with custom script
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.
2025-03-10 19:35:50 +01:00
|
|
|
{
|
2025-03-23 16:24:51 +01:00
|
|
|
diffutils,
|
postgresql: replace pg_config with custom script
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.
2025-03-10 19:35:50 +01:00
|
|
|
lib,
|
|
|
|
|
replaceVarsWith,
|
|
|
|
|
runtimeShell,
|
2025-03-23 16:24:51 +01:00
|
|
|
stdenv,
|
postgresql: replace pg_config with custom script
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.
2025-03-10 19:35:50 +01:00
|
|
|
# PostgreSQL package
|
|
|
|
|
finalPackage,
|
|
|
|
|
}:
|
|
|
|
|
|
|
|
|
|
replaceVarsWith {
|
|
|
|
|
name = "pg_config";
|
|
|
|
|
src = ./pg_config.sh;
|
|
|
|
|
dir = "bin";
|
|
|
|
|
isExecutable = true;
|
|
|
|
|
replacements = {
|
|
|
|
|
inherit runtimeShell;
|
|
|
|
|
postgresql-dev = lib.getDev finalPackage;
|
|
|
|
|
};
|
2025-03-23 16:24:51 +01:00
|
|
|
nativeCheckInputs = [
|
|
|
|
|
diffutils
|
|
|
|
|
];
|
|
|
|
|
postCheck = ''
|
|
|
|
|
if [ -e ${lib.getDev finalPackage}/nix-support/pg_config.expected ]; then
|
|
|
|
|
diff ${lib.getDev finalPackage}/nix-support/pg_config.expected <($out/bin/pg_config)
|
|
|
|
|
fi
|
|
|
|
|
'';
|
postgresql: replace pg_config with custom script
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.
2025-03-10 19:35:50 +01:00
|
|
|
}
|