Split it up now into 2 separate commits, so the actual change becomes more clear and is not obscured by the move of kmail.nix → kmail/default.nix in 57f182c.

Rebased + conflicts solved.

ping @ttuegel

ping @eliasp

Usually, we would add the paths in the wrapper. Is there a reason we must patch the source here, instead?

No reason - I just wasn't aware of this way. Fixed that & threw away my little more complicated approach 😄

libsForQt5.kmail: Ask if output path share/doc (5.6M) could be split with outputs = [ ... "doc" ];

See 2e2ab21 - is that what you asked for?

Not sure if bin and lib make sense here. You most likely need them anyway. I think $out and $doc are enough.

Not sure if bin and lib make sense here. You most likely need them anyway. I think $out and $doc are enough.

Makes sense - it's fixed now. Thanks!

Is this still waiting on something? I can offer to test this on my system, although I cannot promise to hit all use cases that then call external programs.

IMHO nothing left to be done for merging here… I addressed all open issues so far.

Successfully created backport PR #127332 for release-21.05.

While testing #127332 I discovered that this PR only resolves this issue for KMail when being run via kmail, but not when embedded as a port of kontact.
I could just apply these changes to the kontact derivation as well, but that introduces code redundancy and the need to maintain changes for 2 files.

Any ideas for a cleaner solution? One way would be to expose the external KMail dependencies through a `passthru? attribute and then use these in the kontact derivation. But corrently, kontact does not even use kmail as an input 😕

Does Kontact embed KMail as KPart? Then my first approach would probably have made this work.

Yes, that's how I understand it. The kontact derivation doesn't take kmail as an input, but takes kparts and then probably makes a run-time discovery (yay, impure) of what PIM components are available.

Yes, it is definitely using KParts to embed KMail: When I just built kontact from the commit specified above (based on unstable), it failed to load the KMail part with this error:

Cannot load part for Mail. Cannot load library /home/spiollinux/.nix-profile/lib/qt-5.15.2/plugins/kmailpart.so: (/nix/store/z3lf066csyma75624syd2vcklry8vqhd-glib-2.68.2/lib/libgobject-2.0.so.0: undefined symbol: g_memdup2)

So for proper testing, I might need to overlay the whole KDE ecosystem. Or backport your changes.

Even if the patches proposed by @eliasp work, we need to weigh the effort of maintaining them with the drawbacks of the simple wrapper solution and wrapping both kmail and kontact separately.

Do you think your patches also work on other distros and are thus upstreamable? Because then this might be a clear reason to adopt that approach.

No, those patches are quite NixOS-specific (hardcoding the binary path for external applications called via QStandardPaths::findExecutable() to their store path), as on all other distros, said external applications should be located dynamically based on the runtime environment's $PATH.

Auto-patching all usages of QStandardPaths::findExecutable() during buildtime (even for all other Qt applications) won't work as well, as there's no proper way to always determine the application to be executed.

So wrapping kmail + kontact seperately seems to be most reasonable approach IMHO.