I used the Nix Package Manager, via nix-shell, to temporarily install podman on CentOS 7.9 to see if the upgraded version worked.
podman 5.0.3 didn’t work. There were keys and container sources in place from the original platform install of podman 1.6.4. So, I exited nix-shell, uninstalled the yum packages and moved the /etc/container, /user/share/container, and ~/.config/container directories to backup and hoped that the Nix Package Manager “re-install” would re-create them for the Nix context. It didn’t.
Is there a way to force the package to generate the configurations?
I think that since I already have the package in the store, that Nix is just re-creating a temporary environment with links pointing to the right places. I suspect (sorry noob here) that if it was a first time install it would have created those configuration files, but that it elects not to over-write them if they exist already. A sensible default. But if I re-run
nix-shell -p podman
a second time, it finds the package that it downloaded earlier in the store and just re-establishes the links. I can’t seem to find any option to regenerate the config files, assuming I’m right in my guess about what it would have done on the first install.
Although Podman complaining about missing global policy.json while a local one is present #19073 is a different problem, it gives me some confidence that my assumptions are correct, that nix-shell should be creating the configuration files.
I’m thinking that running nix-shell with --expr and some derivation that triggers the package re-install might be the way to go… now to figure out how to do that 
Your idea is a bit twisted… Nix makes installations reproducible. Now, if “reinstalling” it (although just with nix-shell) the behavior of the application is always the same, it probably means that in one of the previous invocation the command has persisted on disk some kind of additional config that now re-reads everytime is run… probably in you home directory, that Nix usually doesn’t touch. Have you tried deleting your user’s podman config?
twisted…
Guilty as charged 
Have you tried deleting your user’s podman config
Yes, my backup nuked all of that, including userland.
That was actually overkill, so I used yum to reinstall, then uninstall, which generated enough configs that Nix version could complain about a missing policy. Since I was hacking, I copied the backup policy from /etc/containers to userland, then I could pull images, but not run them. There’s some namespace binding problem… and I’ve run out of day, and am doing too much hacking.
P.S. great reference link. 
For posterity… one thing I think should be pointed out is that using the podman package on NixOS is fine, but, if using Nix Package Manager on a guest OS, that package is not likely to work because podman requires deep integration into the internals of the host OS, like cgroups and namespaces and other things.
As the podman page on the nixos wiki mentions points out:
Note that rootless podman requires newuidmap (from shadow). If you’re not on NixOS, this cannot be supplied by the Nix package ‘shadow’ since setuid/setgid programs are not currently supported by Nix.
One is typically better off installing podman or Docker on the host using the hosts installer or package manager. Since my host was constrained to a really old version with only an ancient version of podman that had problems, I was hoping that the Nix Package Manager would be a nice work-around. For most things it is, but not for podman due to these problems.
However, if a working podman is available on the host, then nix-shell with the Nix Package Manager is an excellent way to build containers.