Bug#1007994: qtpaths is broken for cross compilation

[Helmut Grohne <helmut@subdivi.de>]

Package: qttools5-dev-tools
Version: 5.15.2-5+b1
Severity: important
Justification: multiarch violation
User: debian-cross@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