Since we are calling it with libsForQt5.callPackage, you don't have to manually use wrapQtAppsHook. The qt provided mkDerivation will do the trick (instead stdenv.mkDerivation).

@peterhoeg Does the core actually need wrapping...? I'll go find out, I guess.

I'm pretty sure you should wrap the core as well.

@ttuegel @worldofpeace I tested, quasselcore runs fine without wrapping. It does still use Qt, but it appears that all its Qt dependencies are compile-time -- there's apparently no run-time dependency on any plugins, and obviously not on any style engines or other GUI components.

It does still use Qt, but it appears that all its Qt dependencies are compile-time -- there's apparently no run-time dependency on any plugins, and obviously not on any style engines or other GUI components.

IIRC, it doesn't link libQt5Gui.so, so this sounds good.

Oh, dang, I didn't think of searching before writing a fix... #67746 solves the issue by using mkDerivation as given by callPackage, and removes the dangerous with stdenv;. Should we prefer using the right mkDerivation over re-implementing the patch logic?

Though, I guess this becomes an issue with quasselCore. Well, it does work fine when wrapped, so maybe it's a non-issue?

Though, I guess this becomes an issue with quasselCore. Well, it does work fine when wrapped, so maybe it's a non-issue?

Doesn't that mean quasselCore will end up pulling in extra runtime dependencies...?

Doesn't that mean quasselCore will end up pulling in extra runtime dependencies...?

I guess it's possible, then switching which mkDerivation to use on whether it needs Qt is probably the better option in that case. I just pushed that change. The core does start when using stdenv.mkDerivation (as expected). In my case everything else was a no-op compared to the state before the change.

@samueldr That seems a lot less clear as to what it is actually doing, though, because the difference between mkDerivation and stdenv.mkDerivation is not apparent to someone reading the derivation expression. Even assuming they're familiar with libsForQt5.mkDerivation, they still need to either check the call site or make the assumption that libsForQt5.callPackage was used there.

Actually, I guess that's more of an issue with the 'use a custom deriver' approach in general.

#67746 superseded this.

OK. I am feeling a little disappointed at the course of events here. I do not think that both PRs should have remained open; I believe that ideally either @samueldr should have closed theirs, or they or another maintainer should have asked me to close this one, in order to to ensure that further discussion and work continued in a single place rather than being confusingly fragmented.

OK. I am feeling a little disappointed at the course of events here. I do not think that both PRs should have remained open; I believe that ideally either @samueldr should have closed theirs, or they or another maintainer should have asked me to close this one, in order to to ensure that further discussion and work continued in a single place rather than being confusingly fragmented.

Indeed it did get a little messy.
From my perspective, as an integrator, neither of the changes purposed actually moved along with the changes that needed to happen for me to integrate them. So when I got the time today I finished c52b5b8 (why it says co-authored). In the end the same goal was achieved, it's not broken, but I do understand the means to this weren't optimal. @Shados In the future I'll take extra measure to give direction to changes with competing PRs.