SSIA - after some QT update, I cannot run qtconfig looks like some hardcoded paths need updating ... $ qtconfig qtconfig: could not exec '/usr/lib64/qt5/bin/qtconfig': No such file or directory $ which qtconfig /usr/bin/qtconfig $ /usr/bin/qtconfig qtconfig: could not exec '/usr/lib64/qt5/bin/qtconfig': No such file or directory $ equery b /usr/bin/qtconfig * Searching for /usr/bin/qtconfig ... dev-qt/qtchooser-0_p20151008 (/usr/bin/qtchooser) dev-qt/qtchooser-0_p20151008 (/usr/bin/qtconfig -> qtchooser)
qtconfig tool exists in Qt 4 (/usr/lib64/qt4/bin/qtconfig from dev-qt/qtgui:4), but not in Qt 5. A third-party configuration tool for Qt 5 is provided by x11-misc/qt5ct. Qt team: Maybe /usr/bin/qtconfig symlink should be deleted?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Qt team: Maybe /usr/bin/qtconfig symlink should be deleted? No, why? The whole point of qtchooser is that users and developers can use a command-line option or an env variable to switch between qt4 and qt5 without specifying full paths to binaries. We may do that once qt4 is treecleaned, but not yet.
(In reply to Davide Pesavento from comment #2) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > > Qt team: Maybe /usr/bin/qtconfig symlink should be deleted? > > No, why? The whole point of qtchooser is that users and developers can use a > command-line option or an env variable to switch between qt4 and qt5 without > specifying full paths to binaries. We may do that once qt4 is treecleaned, > but not yet. ahem, I don't get it why do you close this bug - it simply doesn't work in default configuration, so I don't see what is "INVALID" about reporting that a binary searches nonexistant path ... if a qt4 app doesn't have its qt5 counterpart then what is the point in pretending so but failing to execute? (In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > A third-party configuration tool for Qt 5 is provided by x11-misc/qt5ct. thanks for the pointer um, "after some QT update" - sounds funny when it concerns 4=>5, but I really hadn't run it in ages :-)
Anyway if you use KDE Plasma, then you do not need qtconfig or qt5ct. (Qt 5 applications would respect KDE settings.)
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4) > Anyway if you use KDE Plasma, then you do not need qtconfig or qt5ct. (Qt 5 > applications would respect KDE settings.) I use LXQt on that machine; there are some problems now, also when running apps remotely via ssh, so I wanted to check what Qt settings are applied independently on the DE
Bump.
I still don't fully understand what problems the dangling symlink causes. And it's not just qtconfig, you will likely have several more, such as qdoc3 and qml1plugindump. As I said, this is entirely expected. This is the approach upstream has chosen to support side-by-side installations of different major versions of Qt and I don't see any reasons to deviate from it.
Je pense que merci pour les informations et les idées précieuses que vous avez fournies ici. https://bit.ly/3eTChie
*** Bug 828577 has been marked as a duplicate of this bug. ***