VectorChord requires its indexes to be reindexed when the extension is
updated. [1]
This commit adds functionality to save the current version of the
extension before performing an update, and then compare it with the
updated version to decide whether it should reindex Immich's indexes.
This complexity is needed to avoid reindexing every time PostgreSQL is
started, as it is an expensive operation that would slow down startup.
[1]: https://docs.immich.app/administration/postgres-standalone/#updating-vectorchord
Without the change the attribute refers to deleted file:
+ nix build --no-link -f. nixosTests.nixseparatedebuginfod
error:
error: path 'nixos/tests/nixseparatedebuginfod.nix' does not exist
Since I started touching this subsystem, I found the name confusing
since this is the part where we actually compile the kernel and we have
a ready-to-use configuration.
The stated goal of the commit introducing it[1] is to provide a function
to
> make it possible to build a kernel with a user provided .config.
Considering that this is supposed to be a differentiation from other
build mechanisms and nowadays this is the only way to build kernels in
nixpkgs, I figured that `build.nix` is a better name.
`pkgs.linuxManualConfig` isn't renamed on purpose: Kloenk and I are
planning to do more involved work and it may become necessary to change
parts of the API. So asking users to do a migration now just to add
another one soon isn't worth it.
[1] bf7467cbb1
This is something I introduced in 63185299f4
to make sure the `version`/`src` attributes point to the files that declare
the version such that we get pinged by ofborg for updates.
This is long obsolete since the versions are maintained in a JSON file
now. Also, the kernel team is listed as owner in the ci/OWNERS file for
the entire subtree, so we definitely get pinged by CI nowadays.
Hence, remove the hackery.
This is in principle, what Alyssa was already doing[1], but I re-did it
because rebasing this against reformats felt too annoying. The previous
attempt was reverted because of unrelated regressions in the chain.
The `drvAttrs` function made the entire code far more cluttered, harder
to understand and didn't serve a real purpose since it was just used a
single time.
I also got rid of the `kernelConf`-variable and decided to directly use
`stdenv.hostPlatform.linux-kernel`, making it more clear where the
attributes are actually coming from.
[1] f521f46133
Co-authored-by: Alyssa Ross <hi@alyssa.is>
