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? Quite obviously, qtpaths is architecture dependent. Thus we need an instance of it that happens to be architecture aware. Most likely that'd be both of /usr/bin/<gnutriplet>-qtpaths and /usr/lib/<multiarchtriplet>/qt5/bin/qtpaths. While the latter may look present, we really mean the host architecture one here. Step 1: Construct a qtpaths wrapper script that makes it return output for a given architecture instead of the native one. We've done this e.g. for qmake already, but I couldn't figure out how to make it work for qtpaths. I couldn't find an option for qtpaths similar to -qtconf for qmake. Is there anything better we can do than replacing it entirely with a shell script? Step 2: Split packages. qttools5-dev-tools quite obviously cannot continue being Multi-Arch: foreign. So much of it must be moved to a new Multi-Arch: foreign package qttools5-dev-tools-bin. Then a new and almost empty qttools5-dev-tools Multi-Arch: same package depends on qttools5-dev-tools-bin. That way no client package is broken. Initially qttools5-dev-tools keeps /usr/lib/<multiarchtriplet> and everything else moves to qttools5-dev-tools-bin. Step 3: Add the wrapper script from step1 to qttools5-dev-tools. That probably replaces the present symlink /usr/lib/<multiarchtriplet>/qt5/bin/qtpaths. Note that steps 1 and 2 can be performed in parallel and independently. Starting step 2 early is paramount as it will trip through new. What happens to /usr/bin/<gnutriplet>-qtpaths is very unclear to me. It's even unclear whether we need it at all given that packages seem to prefer picking a qt installation root (e.g. /usr/lib/<multiarchtriplet>/qt5) and then locating everything from there. If we need it, we likely need to involve qtchooser in order to support qt6. So does this make sense from the qt-maintainers pov? Helmut
