Cannot review at the moment but the main problem I had with this the last time I attempted this is that gdk_pixbuf appears in patches as a part of projects’ source code very often. And also since gdk-pixbuf is not a valid bash variable, we cannot use it in substituteAll.

It would be best to start by making an alias. And keep it like that for one release. That way it will be easier to back-port security fixes.

@zimbatm This pr has always included an alias in aliases.nix.

I mean one solution would be to merge the alias now, and then do the rename and swap the aliases in the next release.

@zimbatm If I were to merge that alias in aliases.nix wouldn't that cause eval-package-list-no-aliases to fail indefinitely until all references to gdk_pixbuf are removed from nixpkgs?

@worldofpeace I don't know. Sorry for holding the PR back, I guess renaming things directly will be ok too.

@peti would it be appropriate after this is merged to manually update the haskell package set?
I think that's the way to go about this. You'd need to merge NixOS/cabal2nix#424

@peti would it be appropriate after this is merged to manually update the haskell package set?

Yes, I think so.

You'd need to merge NixOS/cabal2nix#424

Done.

@peti Is merged 👍

evaluation of staging is failing:
https://gist.github.com/GrahamcOfBorg/d4200600779484deceb3c72071a9fe87

Yeah that's expected, it needs to be manually updated...

What do you mean expected? Failing builds is one thing, but failing evaluation is another. Can we do a simple sed substitute?

You can't/shouldn't manually change anything in haskell-packages.nix.
NixOS/cabal2nix#424 was merged so it can be regenerated using the new name, but this change had to happen before that. If I were to just manually change it without that it would have regenerated using the old name.

Since I have no control over the haskell infustructure in nixpkgs and know very little of it, I'm expecting @peti to correct this and why I expected this to happen. I'm waiting for it to be corrected because it's out of my control.

For now we can just do a substitute until. It does no harm and when the next time someone (likely @peti) generates the set it will be fine anyway.

I won't re-generate the package set for at least one week or longer as I'm on vacation. Generally speaking, I never re-generate anything in staging where this PR went.

I would suggest manually seding hackage-packages.nix until then.

#65487