aliases: make aliases supported for 2 years/4 releases

[pbsds]

There seems to be no set expectations on how long an alias is supposed to be supported, and some are dang near ancient. Dropping aliases is however scary since most downstream users use allowAliases=true and thus see no warning that the attribute they rely on is technically deprecated. So when aliases finally do get dropped it "comes out of nowhere" for most users (the post-merge reactions in #349431 still stick with me...).

#414658 however fixes that, so conditioned on it being merged I propose 2-year (or possibly shorter) support for aliases.

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/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (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.

[Pandapip1]

I'm definitely in favor of a more clear-cut timeline for this. Ideally there would also be a corresponding timeline to remove throws too but that would expand the scope of this PR.

[Pandapip1]

Nitpick: Who is 'we'? The release manager? If so, this should probably be documented in whatever checklist is used. If it's not a defined person at all, I'd be surprised if this ever happens.

Alternatively, there could be a CI that periodically runs the script and opens a new PR. If this is the route that ends up happening, I don't think it would be out of scope to mention that intention here.

[pbsds]

I went for an ambiguous "we" due to not having put it on any release checklist yet, and instead phrasing it as an open invitation. Once merged we could open a PR to the release-manager repo, then update this text if that gets merged.

The script is too faulty to be run automatically IMO. It should be cherry-picked by a human.

[pbsds]

I'm definitely in favor of a more clear-cut timeline for this. Ideally there would also be a corresponding timeline to remove throws too but that would expand the scope of this PR.

I propose we keep throws for an additional two years, to prevent the case where someone bumps nixpkgs ahead by two+ years then running into horrible to diagnose issues due to some package having been dropped then replaced by something different using the same name.

[mdaniels5757]

Just found this. (Of course I only bothered to look after making #427017...)

I think some clarity would be nice, but 2 years seems long. I'd propose:

• All aliases (except the ones that we intend to keep permanently) are transitioned to warnings. (Either through aliases: warnOnInstantiate all aliases if config.warnAliases=true #414658 or maintainers/scripts/remove-old-aliases.py: convert aliases to warnings before throwing or removing; aliases: cleanup #427017.)
• Any alias can become a warning at any time.
• A warning can become a throw after 1-3 release cycles. (I think I'd lean towards 1 or 2, but perhaps 3.)
• Consistent with the policy that "all broken packages... will be removed after a full NixOS release cycle" (RFC 180), a throw can be dropped after 1 release cycle.

[wolfgangwalther]

We're working on the by-name basics for #442066, which would encode a policy for this into those structured aliases. The idea is to progress them from warning to throw automatically and cause a CI failure when bumping the nixpkgs version number, so that they will be dropped.