After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
This replaces `writeShellApplication` with `writeShellScriptBin` that
doesn't perform a shellcheck. This makes it way easier to build
postgresql on staging since GHC is super slow to build, even with pretty
powerful machines.
Also Haskell updates are currently merged straight into master which
means that postgresql and all reverse dependencies require a rebuild on
master then[1].
[1] https://github.com/NixOS/nixpkgs/pull/354270#issuecomment-2463196665
(cherry picked from commit 4cd083a3cd)
(cherry picked from commit a40d887561)
This enables update scripts via buildPostgresqlExtension. Extensions
must actively opt-out, if they don't support either the default
configuration or the unstable configuration.
To make the update script work, some extensions had to be changed to
pull their code from GitHub instead. Those with PostgreSQL-style version
tags (REL_X_Y) had to be changed to make src.rev the source of truth.
This will be EOL at the end of November, so there's little reason to
keep it in 24.11[1]. As discussed, we'd like to keep it for as long as
possible to make sure there's a state in nixpkgs that has the latest
minor of postgresql_12 available with the most recent CVEs fixed for
people who cannot upgrade[2].
This aspect has been made explicit in the manual now for the next .11
release.
During the discussions it has been brought up that if people just do
`services.postgresql.enable = true;` and let the code decide the
postgresql version based on `system.stateVersion`, there's a chance that
such EOL dates will be missed. To make this harder, a warning will now
be raised when using the stateVersion-condition and the oldest still
available major is selected.
Additionally regrouped the postgresql things in the release notes to
make sure these are all shown consecutively. Otherwise it's a little
hard to keep track of all the changes made to postgresql in 24.11.
[1] https://endoflife.date/postgresql
[2] https://github.com/NixOS/nixpkgs/pull/353158#issuecomment-2453056692
