Strange issue: one particular overlay is ignored (ineffective)

Learn
#1

I’m facing a strange issue:
I need recent fixes in podman and defined an overlay to get podman-4.1.0:

self: super:

{
    podman = super.podman.overrideAttrs (old: rec {
        pname = "podman";
        version = "4.1.0";
        src = super.fetchFromGitHub {
            owner = "containers";
            repo = pname;
            rev = "v${version}";
            sha256 = "sha256-3MR4ZhkhMLAK3KHu7JEV9z1/wlyCkxfx1i267TGxwt8=";
        };
    });
}

With rebuild it is evaluated (I can see that because a wrong sha256 leads to an error) but the derivation is not actually placed in the nix store and not available, even though I have multiple references using pkgs.podman.

If instead I choose podman.unwrapped = super.podman.unwrapped.overrideAttrs ... it appears to have more effect (the package is actually being built), but I get build errors like

> make: *** No rule to make target 'install.man-nobuild'.  Stop.

So the question: why does this overlay not work and how to correctly apply this kind of overlay (where apparently system modules might refer both to the wrapped and unwrapped versions)?

#2

I’d start by doing

self: super:

{
    podman = (x: builtins.trace x x) (super.podman.overrideAttrs (old: rec {
        pname = "podman";
        version = "4.1.0";
        src = super.fetchFromGitHub {
            owner = "containers";
            repo = pname;
            rev = "v${version}";
            sha256 = "sha256-3MR4ZhkhMLAK3KHu7JEV9z1/wlyCkxfx1i267TGxwt8=";
        };
    }));
}
#3

The trace gives a lot of information, but it’s all env vars and settings. It appears that the podman derivation build is not really triggered (I tried forcing it to make some changes to the hashes and changing it back). Other than that I’m not really able to usefully interpret the trace.

Only if I add podman.unwrapped to the overlay something substantial seems to happen (it leads to the podman derivation actually being built), but it leads to build errors.

It mostly begs the question how wrapped and unwrapped versions depend on eachother and possibly how virtualisation.podman.enable = true depends on podman wrapped/unwrapped?

That said, this particular issue appears to be obsoleted now by the fact that now podman-4.1.0 has arrived in unstable.

Unfortunately using podman-4.1.0 still hasn’t solved my original problem (for which I started this)

#4

Oh! If podman is wrapped, you need to overlay the unwrapped version. Overriding podman would only override the wrapper, not the actual build which is probably why you’re getting weird errors.

#5

@Atemu Thanks for following up…
In fact I tried overriding podman.unwrapped early on, but got strange build errors (as if some Makefile rules were strangely patched, even though I couldn’t find how/where):

Mind you, I only overrode the source, the rest of the build recipe doesn’t change by that, and it seems a bit peculiar that there are suddenly targets like ...-nobuild in the (patched?) Makefile?

Hosted by Flying Circus.