@vcunat, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @Ericson2314 and @pSub to be potential reviewers.

I think the problem with Qt5 would be rather avoided by adding _qtRmTmp and _qtFixCMakePaths to $preFixupPhases rather than $postInstallHooks.

Right, that certainly seems less risky in this respect. I guess @ttuegel knows best this stuff.

I think the problem with Qt5 would be rather avoided by adding _qtRmTmp and _qtFixCMakePaths to $preFixupPhases rather than $postInstallHooks.

Then you have the same problem whenever someone overrides fixupPhase. That's less common, but it imposes the same constraint on packagers: don't override any whole phase without running the pre- and post-hooks.

No, changing preFixupPhases adds a new phase between installPhase and fixupPhase, whether they're overwritten or not (it's different from a *Hook).

Yes, you now get screwed if a package specifies phases = ... but that typically causes borkage in any package (because everyone who does that doesn't know they need fixupPhase so now you get manpages in wrong places or huge closures due to not shrinking rpaths).

May I suggest to change the default builder in this respect.
For example, when "make install" does not work, using installPhase = ...; is much more natural than dontInstall = true; postInstall = .... Plus, in the later case, you cannot be sure that your postInstall runse before postInstall hooks.

tl;dr; I think hooks should not be part of the phase, and should not be explicitly overriden if need be.

doc/stdenv.xml also contains this example:

stdenv.mkDerivation {
  name = "fnord-4.5";
  ...
  buildPhase = ''
    gcc foo.c -o foo
  '';
  installPhase = ''
    mkdir -p $out/bin
    cp foo $out/bin
  '';
}

If redefining installPhase is not the right thing to do, then this example should be changed. However (as a newcomer to nixpkgs) I prefer @layus's solution. Keep the simple example for the simple package simple.

Something weird happened. Apparently I did not post this message:

I have a working update to setup.sh that implements my above proposition in layus@66a2bde

To test on only one package, you will need overrideSetup from pkgs/stdenv/adapters.nix.
In particular, it works for #26209.

No, changing preFixupPhases adds a new phase between installPhase and fixupPhase, whether they're overwritten or not (it's different from a *Hook).

@dezgeg Oh, I understand now. Yes, I think that would be the most appropriate solution for the Qt 5 setup hooks. And I agree that although this may break packages that set phases = ..., generally one should not do that unless one understands very very well what one is doing!

Seems pretty good, reminds me of this very unfortunate bit in the nixpkgs manual (a similar bit is in the nix manual) too:

While the standard environment provides a generic builder, you can still supply your own build script:

stdenv.mkDerivation {
  name = "libfoo-1.2.3";
  ...
  builder = ./builder.sh;
}