Control: tags -1 + wontfix On Sun, Mar 20, 2022 at 07:15:16AM +0100, Helmut Grohne wrote: > Package: qttools5-dev-tools > Version: 5.15.2-5+b1 > Severity: important > Justification: multiarch violation > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > Control: affects -1 + src:qt5ct > > Dear qt maintainers, > > we have a bigger problem about qtpaths. I haven't checked, but I think > it also affects qt6. When building qt5ct (and likely others), it locates > qtpaths. We presently have 3 different locations: > * /usr/bin/qtpaths (wrapper for the next) > * /usr/lib/qt5/bin/qtpaths (actual binary) > * /usr/lib/<multiarchtriplet>/qt5/bin/qtpaths (symlink to the second) > > Note that since qtpaths resides in qttools5-dev-tools, which happens to > be Multi-Arch: foreign, the <multiarchtriplet> path is only ever > available for the build architecture and no client package has the > ability to ever select a host architecture qtpaths even if it were > trying to do so. > > qt5ct happens to select the second one. It then runs qtpaths > --plugin-dir and gets back /usr/lib/<multiarchtriplet>/qt5/plugins. > Unsurprisingly, that multiarchtriplet happens to bet the build > architecture one. This is very bad and produces misbuilds. I don't see > any way that qt5ct could improve on this aspect without also changing > qttools5-dev-tools. > > So how do we fix that?
I talked with Sandro Knauß and the answer is that we do not fix it. We recently fixed the same issue in qt6 and there we inserted a -qtconf flag. In case of qt5, such a flag does not exist. It seems to be opening a qt.conf in the same directory as the binary for some invocations, but generally, we cannot influence its behavior to the point we need. Then, qt5 will be deleted from Debian after the trixie release as it is EOLed already. The benefit of spending more effort here does not seem to be warranted. Helmut
