Same thing with the commit message at #79830 (comment).

How does this affect programs using the key for installation?

@worldofpeace fixed
@jtojnar there are no such programs in nixpkgs repo, anyway, if they were, they would not build, since indicatorpath pointed to libdir, and it to the libindicator folder in /nix/store

pkg-config actually supports installing relative to a package prefix, so a package would do

$ libdir=/nix/store/my-app/lib
$ nix-shell -p pkg-config libindicator --run "pkg-config indicator3-0.4 --define-variable=libdir='$libdir' --variable indicatordir"
/nix/store/my-app/lib/indicators3/7/

See https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/

If there are such packages, they would work before but not after this patch removed ${libdir} from the .pc file.

If there are such packages, they would work before but not after this patch removed ${libdir} from the .pc file.

indicator-application-gtk3 and mate-indicator-applet are working. Which may not work?

What's needed for this to be merged?

I do not like this method since it is inconsistent with how we use other foodir pkg-config variables. We typically use it for in-package target paths, not global installation paths – the projects that install stuff to foodir usually outnumber projects that try to read from there (though for ancient libs like this one either might be hard to come by).

For that reason, this should be handled in the individual consumers like mate-indicator-applet in my opinion.