Make sure that JIT is actually available when using
services.postgresql = {
enable = true;
enableJIT = true;
package = pkgs.postgresql_15;
};
The current behavior is counter-intuitive because the docs state that
`enableJIT = true;` is sufficient even though it wasn't in that case
because the declared package doesn't have the LLVM dependency.
Fixed by using `package.withJIT` if `enableJIT = true;` and
`package.jitSupport` is `false`.
Also updated the postgresql-jit test to test for that case.
This is useful if your postgresql version is dependant on
`system.stateVersion` and not pinned down manually. Then it's not
necessary to find out which version exactly is in use and define
`package` manually, but just stay with what NixOS provides as default:
$ nix-instantiate -A postgresql
/nix/store/82fzmb77mz2b787dgj7mn4a8i4f6l6sn-postgresql-14.7.drv
$ nix-instantiate -A postgresql_jit
/nix/store/qsjkb72fcrrfpsszrwbsi9q9wgp39m50-postgresql-14.7.drv
$ nix-instantiate -A postgresql.withJIT
/nix/store/qsjkb72fcrrfpsszrwbsi9q9wgp39m50-postgresql-14.7.drv
$ nix-instantiate -A postgresql.withJIT.withoutJIT
/nix/store/82fzmb77mz2b787dgj7mn4a8i4f6l6sn-postgresql-14.7.drv
I.e. you can use postgresql with JIT (for complex queries only[1]) like
this:
services.postgresql = {
enable = true;
enableJIT = true;
};
Performing a new override instead of re-using the `_jit`-variants for
that has the nice property that overlays for the original package apply
to the JIT-enabled variant, i.e.
with import ./. {
overlays = [
(self: super: {
postgresql = super.postgresql.overrideAttrs (_: { fnord = "snens"; });
})
];
};
postgresql.withJIT.fnord
still gives the string `snens` whereas `postgresql_jit` doesn't have the
attribute `fnord` in its derivation.
[1] https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JIT-ABOVE-COST
A change made in #166308 added `networking.resolvconf.package` to the
`environment.systemPackages` list, so it is installed as part of the
system image. However it does so unconditionally, meaning that even if
the `config.networking.resolvconf.enable` is set to false the package
listed in the `networking.resolvconf.package` would still be intalled.
This change makes it so the package installation will depend on the
status of the `config.networking.resolvconf.enable` option instead.
This adds an option `services.mattermost.environmentFile`, intended to be
useful especially when `services.mattermost.mutableConfig` is set to `false`.
Since all mattermost configuration options can also be set by environment
variables, this allows managing secret configuration values in a declarative
manner without placing them in the nix store.
Before, setting {option}`programs.steam.package` would result in a steam without
the {option}`hardware.opengl.package`, {option}`hardware.opengl.extraPackages`
etc. You had to manually add them yourself.
Additionally, overlaying `steam = prev.steam.override { extraLibraries = [ ... ]; }`
resulted in those extra libraries not actually being put into the fhsenv because
they'd be fully overridden by the option's default.
Now, the user can supply a custom steam to {option}`programs.steam.package` with
its own list of extraLibraries which will not be overridden and overlays work as
expected too.
