Possible improvements:

• Removing qtCompatVersion entirely.
• Ensuring qtCompatVersion is composed only of 5.X.Y, as right now an hypothetical qtbase-5.x.y-1 could realistically cause 5.x.y-1 paths to be looked up into... which may not even be an issue in the end.

Additionally, missing wrapQtAppsHook now fails more decisively at runtime, rather than using whatever traces could be found in the environment.

We should just make these fail at build-time to save everyone a lot of headaches.

This is going to break the following use-case: the user has Qt applications installed in their user and system profiles, then they update the system but not user profile. The user profile applications will not be able to find input methods, themes, etc. anymore. This case works right now, as long as all the version numbers go in the right direction; it's admittedly fragile.

Here are my controversial reasons we may not care about this breakage:

1. nix-env and user profiles were always a bad idea and effort expended supporting them is wasted.
2. The only way to make Qt applications work 100% correctly under Nix is to build them in an FHS chroot and Flatpak them, and everything is going to be broken for somebody until we do that anyway. (This is an exaggeration: we could just rewrite dlopen() instead.)

The user profile applications will not be able to find input methods, themes, etc. anymore.

At least for the input method, I found out that Qt is able to resolve the one I use. I assume, though, it may not end up being true for all of them, and for all things.

(This is an exaggeration: we could just rewrite dlopen() instead.)

I don't think it'd be enough; I think any file access would need to be checked. Isn't there more than .so resources that can be loaded, like QML resources and such? (Though I'm not sure.)

Here are my controversial reasons we may not care about this breakage:

1. nix-env and user profiles were always a bad idea and effort expended supporting them is wasted.
2. The only way to make Qt applications work 100% correctly under Nix is to build them in an FHS chroot and Flatpak them, and everything is going to be broken for somebody until we do that anyway. [...]

I'm still waiting on the controversial bit. I much rather we decisively break under those circumstances, than have almost working, but brittle solutions. It's not ideal to break what seems to be working now, but in the end it should end up being easier on end-users. I'm not even sure that nix-env will break that much, from the limited testing I did.

At least for the input method, I found out that Qt is able to resolve the one I use. I assume, though, it may not end up being true for all of them.

It looks like you are using I-Bus, right? I-Bus is built into Qt. I would be very impressed if you broke it 😀 I would not have a problem if we wanted to say "I-Bus is the only officially-supported input method for Qt," but we have others (at least fcitx) in Nixpkgs.

I don't think it'd be enough; I think any file access would need to be checked. Isn't there more than .so resources that can be loaded, like QML resources and such? (Though I'm not sure.)

Qt only detects version mismatches in the shared object files. The mismatch only occurs because of the order that dlopen searches for dependencies. Basically, plugin shared objects get the opportunity to override the RUNPATH of the process that's loading them, and that's why you get a mismatch. If dlopen processed search paths in the opposite order, the plugin would be forced to use the application's library versions—this is OK because Qt maintains strict ABI compatibility rules for plugins, and it's actually how it works correctly on other distros. But you're right, the only way to be strict about compatibility is to rewrite the kernel (or at least libc) or use a chroot solution like Flatpak.

this PR plus my changes to wireshark (to use the new Qt mechanism) fixed my issue.

Should we change this to go into staging, due to the size of rebuild?

(Oops, I tried to use the git merge-base trick to not ping people, but accidentally used staging when rebasing instead of the merge-base)

@ttuegel the commits are now rebased on the merge-base of staging/master; it can be switched as needed.

Considering Qt says:

Patch releases are both backwards and forwards binary and source compatible.

Why is this even an issue in the first place?

Sorry for the totally unprofessional response, but ¯\_(ツ)_/¯

I think @ttuegel has a better handle on the explanation for that.

It may be that specifics to NixOS and the way it load both Qt versions at the same time is the issue, if it loaded any one (and only one) of the patch-level versions at once, I guess it would be fine? Though, as I initially stated, I don't exactly know. I'm working off of evidence that (1) it's an issue with Qt as packaged withing Nixpkgs, (2) it demonstrably fixes the issue with this PR and (3) missing the wrapper decisively breaks instead of attempting to use a compatible other-patchlevel Qt from the environment.

I'm not at all disputing that there is an issue - and this does seem to be an elegant way to fix it. I just can't help think that there's something we're missing.

Oh, I wasn't aggravated or anything. I, too, am wondering the exact reasons this acts as it does. I would rather know the details to better understand the issue, than using only the observed effects.

Why is this even an issue in the first place?

Although applications and plugins are compatible across patch-level versions, all of the parts of Qt itself need to be of the same version exactly. So, if an application compiled with Qt 5.12.3 tries to load a plugin compiled with Qt 5.12.0, its RUNPATH will be contaminated and it might load mis-matched Qt libraries. This isn't an issue with other distributions because they build the entire Qt installation at once and they have one canonical path (/usr/lib) where all the latest libraries are found.

Another way we could deal with this problem is to compile a monolithic Qt (so there is one canonical path where the Qt libraries are) and use patchelf to remove that path from the RUNPATH of other libraries and plugins, effectively delegating linking to the application. I didn't want to do this because it's not the Nixpkgs Way, even though it is what dynamic linking is for.

I'm getting this problem in 2023, for when I use stable QT, but try to use cura and krita from unstable via flake. :/