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

Control: tags -1 + wontfix

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