Change:
sha256 = "sha256-UOAQtGDoZe+Av4+9RQCJiV3//B/pdF0pEsca4FonGxY="; }; <ins> patches = [ # we intentionally don't build and install the helper so we shouldn't display messages to users about it ./rm-podman-mac-helper-msg.patch ]; </ins> vendorSha256 = null; doCheck = false;

Discussion:
podman suggests you use a non-existant binary. steps to reproduce the behavior: should we try and patch out to prevent new user confusion? we could also try and include , but it seems like it would make things worse, and the right solution is a nix-darwin module? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
No. Carrying patches has been discussed previously by the podman maintainers. See , most of it applies here. IIRC it still hardcodes in places. Yes, it's the path to the unwrapped binary. Yeah guess that would work but fixing it upstream somehow would be better.
How would it make things worse? I think we should probably add to the output and let a user choose whether to use a nix-darwin module (which I think is better but may not fit everyones workflow) or the builtin helper? I don't have a darwin machine to test this on right now but would happily accept a PR adding the mac helper util (and make the wrapper aware of it too).
I concede your point, and am not pushing back, but this one feels like it is in a different class. yep, it does; see below. sure, but even I am unclear exactly how to get it into PATH; non-technical users are going to be lost. what would be your proposed upstream fix? I cannot see a clean way for a tool like podman to keep around a launchctl plist that auto-retargets the correct binary in the . This seems like binaries containing systemd service definitions. does during the install, and I think it fundamentally violates expectations about nix and the store. We certainly include other things (say ) in the nixpkgs do this too, but I would wager users expect them to do that, where here the fact that podman is pinned to a terrifying old version will cause debugging hell?
Yeah, that's fair. If it's just removing those couple of lines I guess we can live with that. I did have a couple of ideas but can't find were I kept note of them. TBH after upstream started publishing installers and the app I didn't really have much hope that they'd be willing to accommodate us.

Also means anything we do to hack/patch around it is that much more fraught.
that is quite a shame, but they are likely trying to cater to the crowd. I am happy to close this out, with a resolution of "we should make home-manager and/or nix-darwin modules", but if there is anything else you maintainers want done to the actual derivation, I am happy to drive that.
Haven't found my notes but one idea I had was to have the podman binary that was being interacted with by the user (and would presumably be the correct/newer one) check that its own path matched what was listed in the plist. This would likely be a bit noisy as it would alert every time the store path changed, less noisy option could be a version check with the version embedded in the plist, less correct but would avoid getting stuck on an old version. I've opened a PR to patch out the message.