Avoid trying to load version-mismatched Qt plugins on NixOS#208
Avoid trying to load version-mismatched Qt plugins on NixOS#208JulianGro wants to merge 1 commit intolinuxdeploy:masterfrom
Conversation
…N_PATH is set on the host. This is often the case on NixOS.
2ce7985 to
7bb3f05
Compare
|
I'm not sure if it's a good idea to do so generally, backwards compatibility is important. I would anyway support making this an optional setting. It at least needs to be opt-out if not opt-in, though. |
| << "# This usually fails due to the mismatched Qt versions." << std::endl | ||
| << "unset QT_PLUGIN_PATH" << std::endl; | ||
|
|
||
| if (qtMajorVersion >= 6) { |
There was a problem hiding this comment.
You mixed up the version check here, this should not be run for Qt >= 6.
|
Thanks for the quick code review. I looked into it some more, and it looks like this is the wrong place to fix this anyway. I initially assumed the NixOS issue is just a case nobody thought about, but Qt's documentation is pretty clear about this: "Do not export QT_PLUGIN_PATH as a system-wide environment variable because it can interfere with other Qt installations." https://doc.qt.io/qt-6/deployment-plugins.html#the-plugin-directory |
|
Yes, it's better for your setup to write a proper |
|
Also see NixOS/nixpkgs#481707 |
This PR unsets
QT_PLUGIN_PATH. This avoids Qt version mismatches when QT_PLUGIN_PATH is set in the host environment. This is often the case on NixOS.I would argue that the chance of someone trying to load an external Qt plugin into an AppImage deliberately is much lower than someone running NixOS with KDE apps installed. Especially since Qt will refuse to load the plugin if the used Qt versions do not exactly match. E.g. 5.15.3 Qt does not allow loading 5.15.18 plugins.