The problem is not with just removing res, but with overrides in general. I've described an example at #55061 (comment), which this PR doesn't touch at all (but problem exists!)

I imagine another solution (at least for pinentry case):

inherit (rec {
  pinentry = callPackage ../tools/security/pinentry {
    libcap = if stdenv.isDarwin then null else libcap;
  };
  pinentry_ncurses = pinentry.override {
    gtk2 = null;
  };

  pinentry_emacs = pinentry.override {
    enableEmacs = true;
  };

  pinentry_gnome = pinentry.override {
    inherit gcr;
  };

  pinentry_qt4 = pinentry.override {
    qt = qt4;
  };

  pinentry_qt5 = pinentry.override {
    qt = qt5.qtbase;
  };  
})
  pinentry
  pinentry_ncurses
  pinentry_emacs
  pinentry_gnome
  pinentry_qt4
  pinentry_qt5
;

In that case there will be no common ancestor, so overrides will behave better (for a while). It is also slightly more verbose, to discourage such pattern use in all-packages.nix.

The changes, which don't use override are fine IMO.

@matthewbauer I don't like res because it's such a global solution to a local problem: nothing else that doesn't need it should be confused by some big extra fix point.

I don't think super will work because the tests would add an overlay after, and pinentry is defined in the same overlay as the super reference so the super will be resolved by "looping back around" to hit the final self. (I'm not totally sure I got this right though.)

The *-real style solution is nice because while it does leak a new name, this allow overriding all at once, which is nice if one wants do a non-variant-specific change. I suggested the "real" suffix because I thought of pinentry as a metapackage like libc vs glibc. But since there's only one pinentry, but many configuration options, something like pinentryBase might be better.

If we don't care about overriding all at once, then @danbst's is the best solution of all as it's truely local. Great idea @danbst!!

I don't like res because it's such a global solution to a local problem: nothing else that doesn't need it should be confused by some big extra fix point.

It doesn't sound that local to me. It sounds like anything using an override (or even aliases) within all-packages.nix could run into this problem. @danbst would work okay, but this would be a lot of recs introduced to support all of the override cases.

My ideal solution would be to move all of these overrides to pkgs/top-level/overrides.nix and make that a proper overlay. I had a PR to do this but I can't find it right now (and it's probably out of date). I think there were some objections to that though. res is basically doing the same thing for us though.

Otherwise, maybe we should just move back to using callPackage multiple times? I prefer using override because it makes it more clear what the "true" package is but we don't want to have this kind of thing broken...

Err my local I meant each instance of the problem, i.e. only the other pinentries need to worry about the base one, be it be given its own name or thrown away as a temporary.

agree about callPackage and moving common stuff to package itself.

@matthewbauer did you change your mind on this?

Regarding pinentry, #49270 will split it into multiple outputs instead of overrides.

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

Closing as dead.