Package installed without error. During usage of other development(PySide2), directions were to compile resource file using QT Resource Compiler (rcc). File could not be located immediately in ${PATH}. Search of the system revealed that multiple QT tools are installed to a library path (/usr/lib64/qt5/bin/rcc). Examination of directory found numerous other Qt support executables. Separation of Qt5/Qt6 has lead to previous install changes. Executable `qmake` is now referenced as /usr/bin/qmake5 and is a simlink back to /usr/lib64/qt5/bin/qmake. Support documentation for gentoo stating to use `qmake5` instead is not widely promulgated. Package dev-qt/PyQt5 has its own resource compiler (/usr/bin/pyrcc5) which is a simlink to a python executable. Execution of pyrcc5 produces different results than Qt version. Manually editing of resulting files to correct is sub-optimal. Installation of qtcore results in missing links to needed support executables that the user can call upon during their development. Gui tools(i.e. Qt-Creator or Designer) may be able to locate and execute tools, but the user does not have visibility to tool set when it is installed to a location outside of ${PATH}.
Sounds like you want to install dev-qt/qtchooser, /usr/bin/rcc is one of the files it'll install alongside unversioned "qmake" and others. There was a news item about this: https://www.gentoo.org/support/news-items/2022-03-30-qt-5_15_3-bump.html
(In reply to Ionen Wolkens from comment #1) > Sounds like you want to install dev-qt/qtchooser, /usr/bin/rcc is one of the > files it'll install alongside unversioned "qmake" and others. > > There was a news item about this: > https://www.gentoo.org/support/news-items/2022-03-30-qt-5_15_3-bump.html From news item: > Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt > binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 [1] such > links will be installed by each respective Qt package and > '5'-version-suffixed, > e.g. qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6. My understanding is that `qtchooser` was dead. From the reading of the news item, I would expect that `uic` and `rcc` would be accessible via commands `uic5` and `rcc5` respectively. These simlinks back to the executables do not exist nor appear to be established.
(In reply to Scott Furry from comment #2) > My understanding is that `qtchooser` was dead. It is for ebuilds, ebuilds shouldn't search for these in /usr/bin nor depend on qtchooser -- thus leading to it being depcleaned and users needing to add it to @world if they need it themselves (news item was mostly to avoid this being a surprise). Also about "mirroring Qt6" in the news item, Qt6 doesn't install rcc6, it even has it in libexec/rcc now (aka not intended to be in PATH) so there's no rcc6 nor rcc5.
(In reply to Ionen Wolkens from comment #3) > ... Not to belabor the point, nor create arguments in the thread to a bug otherwise sapping peoples attention, but where are the details of how Gentoo Qt5/6 install differs from the Qt documentation? I get it, Gentoo is different. It has built up an infrastructure with time to accommodate multiple use cases. Find supporting docs to explain what deviations exist and rationale for deviations seem to be missing. This is just a single example and beyond scope of bug. I was not previously able to locate a consistent and canonical source saying "When installing [Qt{5,6}, PySide{2,6}, PyQt{5,6}] go here | do this". Gentoo wiki page (https://wiki.gentoo.org/wiki/Qt) mentions `qtchooser` but only in relation to qmake. No other tools are mentioned. That section also shows lib path for x32 install. Also, wiki page contains a link to emerge sets: qt5-tools, qt5-essentials, and qt5-addons. None of these sets contains a reference to `qtchooser` ebuild. Maybe I got spoiled by the Arch Linux wiki pages, referenced from Gentoo wiki page itself.
1) Read the news, "mirroring Qt6" means exactly that 2) Everyone can change the Wiki (In reply to Scott Furry from comment #0) > Package dev-qt/PyQt5 has its own resource compiler (/usr/bin/pyrcc5) which > is a simlink to a python executable. Execution of pyrcc5 produces different > results than Qt version. Manually editing of resulting files to correct is > sub-optimal. File a bug against dev-python/PyQt5 with details if you think there is a bug.
(In reply to Scott Furry from comment #4) > I was not previously able to locate a consistent and canonical source saying > "When installing [Qt{5,6}, PySide{2,6}, PyQt{5,6}] go here | do this". Everything "*6*" is still in flux and masked for exactly that reason.
(In reply to Scott Furry from comment #4) > I get it, Gentoo is different. No. Up until Qt6 there simply was no standard way of making non-colliding Qt{1..5} installations. Downstreams came up with various ways of doing it, using different suffixes in $PATH, symlinks, hardlinks, qtchooser, and upstreams picked up whatever downstream environment they were working with in their build systems. You can't rely on any of that, which is why we made an effort to fix upstreams in bug 544108.
More info: https://archives.gentoo.org/gentoo-dev/message/5f3681b5b28dabeb5339d44e9585d29f
(In reply to Andreas Sturmlechner from comment #5) > 1) Read the news, "mirroring Qt6" means exactly that > 2) Everyone can change the Wiki > > (In reply to Scott Furry from comment #0) > > Package dev-qt/PyQt5 has its own resource compiler (/usr/bin/pyrcc5) which > > is a simlink to a python executable. Execution of pyrcc5 produces different > > results than Qt version. Manually editing of resulting files to correct is > > sub-optimal. > File a bug against dev-python/PyQt5 with details if you think there is a bug. PyQt5 was used as an example where there is a resource compiler available in executable path. I needed to also state why this method was not suitable - `pyrcc5` produces files meant for PyQt5 usage. It functions as expected but only applicable to PyQt5 development.
(In reply to Andreas Sturmlechner from comment #7) > (In reply to Scott Furry from comment #4) > > I get it, Gentoo is different. > No. Up until Qt6 there simply was no standard way of making non-colliding > Qt{1..5} installations. Downstreams came up with various ways of doing it, > using different suffixes in $PATH, symlinks, hardlinks, qtchooser, and > upstreams picked up whatever downstream environment they were working with > in their build systems. You can't rely on any of that, which is why we made > an effort to fix upstreams in bug 544108. And the insight to history explains a few things. I did not have a Maintainer's perspective until now.
(In reply to Andreas Sturmlechner from comment #5) > 2) Everyone can change the Wiki > The catch is being comfortable with knowledge to explain it to others. I do not have that. Gentoo build system, especially certain packages such as Qt, are all a black box to me. Wading through bash scripts to wrap my head around state changes for software install, for me anyways, is not the best use of limited time. Web searches are futile producing results with far too many "rabbit holes" to distract.
(In reply to Scott Furry from comment #9) `pyrcc5` produces files meant for PyQt5 usage. It functions as expected but > only applicable to PyQt5 development. Ah, I misunderstood at first, sorry. (In reply to Scott Furry from comment #11) > (In reply to Andreas Sturmlechner from comment #5) > > 2) Everyone can change the Wiki > > > > The catch is being comfortable with knowledge to explain it to others. I do > not have that. For us it is the other way round, it is not always obvious what is necessary to communicate.
The change to bug name, IMO, is erroneous. This is not a documentation problem. The simlinks to select support executables do not exist. Futile to document something that isn't there to begin with. Please reconsider the bug title as it mischaracterizes the issue at hand.
There will be no change to symlinks, it is unclear to me what more explanations are required here. The call for better documentation otoh is valid so that is the only reason to keep the bug open.
(In reply to Andreas Sturmlechner from comment #14) > There will be no change to symlinks, it is unclear to me what more > explanations are required here. The call for better documentation otoh is > valid so that is the only reason to keep the bug open. Seems a bit of a waste and inconsistency. There are other qt-based executables from /usr/lib64/qt5/bin that are "relabeled" with a simlink suffixed with qt version present in /usr/bin. However, the executables that a user may need such as the resource compiler, rcc (as originally pointed out), that have not been given the same treatment. It is this inconsistency and not providing a clear, logical structure is why I open the bug in the first place. Suggesting that this is just a documentation problem is tantamount to saying "Won't Fix". If that's the case, let's just close the bug and stop wasting electrons.
(In reply to Scott Furry from comment #15) > There are other qt-based executables from /usr/lib64/qt5/bin that are > "relabeled" with a simlink suffixed with qt version present in /usr/bin. Yes, because that's what upstream recommends for Qt6 and we're simply following that, as was pointed out above. > However, the executables that a user may need such as the resource compiler, > rcc (as originally pointed out), that have not been given the same > treatment. Qt upstream does not consider rcc a "user-facing" tool, therefore it should not be installed in /usr/bin. If you don't like that, complain to Qt upstream devs. And please note that /usr/bin/rcc has always been provided by qtchooser, not by qtcore (which installs into /usr/lib64/qt5/bin). Now the difference is simply that qtchooser is no longer installed by default with other Qt5 packages. If for whatever reason you want rcc in PATH, go ahead and emerge dev-qt/qtchooser.
