postgresql: plugin pg_embedding is no longer maintained

[longregen]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Thanks for contributing!

Could you please point this PR at the master branch instead?

Also the commit message should start with postgresqlPackages.pg_embedding: ... and could maybe contain a link to the upstream migration guidelines.

[longregen]

Thanks for contributing!

Could you please point this PR at the master branch instead?

Also the commit message should start with postgresqlPackages.pg_embedding: ... and could maybe contain a link to the upstream migration guidelines.

Thank you so much for your patience with reviewing my first contribution to nixpkgs. I changed the PR as requested.

[wolfgangwalther]

@Ma27 WDYT, is this the proper way to deal with that case?

[Ma27]

Eh, that's one of the cases where the RFC127 problems infrastructure would be super-useful.
I do recall discussions where this approach was rejected since knownVulernabilities is supposed to be used for - well - vulnerabilities.

What prevents us from removing the package entirely though? If it's dead and there's a documented migration path. If people need more time for updating, they can still pull in the extension from an older nixpkgs and override it to build against a newer postgresql.

[wolfgangwalther]

Eh, that's one of the cases where the RFC127 problems infrastructure would be super-useful.

Agreed.

What prevents us from removing the package entirely though? If it's dead and there's a documented migration path. If people need more time for updating, they can still pull in the extension from an older nixpkgs and override it to build against a newer postgresql.

Right. What about this in .../ext/default.nix instead, then?

pg_embedding = throw "As of Sept 29, 2023, the authors have abandoned the project and strongly encourage using pgvector, which is faster, has more functionality, and is actively maintained: check out the author's instructions to migrate at https://neon.tech/docs/extensions/pg_embedding#migrate-from-pg_embedding-to-pgvector";

Or would you just remove it without that?

In any case, we'd have to wait until 24.11 is branched off.

[Ma27]

Or would you just remove it without that?

I think those throws are fine. It's just a general trend that these should only exist when config.allowAliases is true to make it easier to evaluate whole attribute-sets (I think).

In any case, we'd have to wait until 24.11 is branched off.

Uhh yeah, right. I really should add those dates to my calendar 🤡

OTOH the rule was originally introduced to avoid disruptive changes while trying to stabilize master. cc @RossComputerGuy @wegank as RMs, what's your stance on removing leaf-packages that are dead in this phase? The release wiki doesn't go into much detail of what we mean with breaking changes and there's even a Pre-release cleanup section in https://nixos.github.io/release-wiki/Feature-Freeze-Announcement.html.

So, my suggestion is:

• if we get an ACK from the RMs, we kill the package now.
• if we get a NACK, we'll kill it right after branch-off. Even though knownVulnerabilities is supposed to be used for actual vulnerabilities only, I'm inclined to mark it as insecure (or broken) regardless.

WDYT @wolfgangwalther @longregen ?

[RossComputerGuy]

I think kill after branch off is best. We at least get people to be aware of the alternative listed in the known vulnerabilities list in 24.11. The following release would remove it with a throw in the aliases to recommend the alternative package.