[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Lisandro Damián Nicanor Pérez Meyer wrote:
> With my distro-packager hat on I realize the best solution would have been
> indeed using prefixed binaries

Please make them suffixed (*-qt5), which is the established convention. 
(Debian also used *-qt4 suffixes in the days where you shipped Qt 3 and 4 
side by side. So did other distros such as Mandriva.)

> That ship already sailed for Qt5, but we might want to revisit it for Qt6.

I think that a rename can be phased in at any time, just shipping both 
(upstream! Distributions like Fedora that never shipped unsuffixed binaries 
in /usr/bin would of course still not do so, there's no change for those) 
and recommending that all users move to the suffixed versions. It can easily 
be done in 5.5. (Technically, even in 5.4.1 or 5.4.2, but that would be 
against the policies for point releases.) Then it'd also be less of a 
surprise (and encounter less resistance) to kick out the unsuffixed binaries 
in Qt 6.

> It has it's drawbacks, too. For example qtchooser needs to be installed in
> order for Qt4 and Qt5 to coexists without breaking a user's system.
> Installing it means that it starts to ship symlinks for tools that might
> not be installed, like for example lrelease. And I think we agree that
> lrelease is not a tool a user wants, so installing it as a dependency is a
> non.go. And after all, should we install the qt4, qt5 or both versions?
> 
> It will also mask tools that are only shipped in one Qt version, like
> qtconfig. Yes, I could simply make qtchooser not ship that symlink and
> make qtconfig's package ship it, but then I'll break developers' flows.

These are good points, and additional reasons why qtchooser is a no go for 
Fedora.

> Multilib as it is in Debian is only for libs and headers. qtchooser's
> config files are shipped within /usr/lib/<arch triplet>/qtn/<someplace>
> because they content differs between archs, so making it arch-dependant.
> 
> Thiago was very kind to accept some patches for this to happen.
> QTCHOOSER_GLOBAL_DIR is used to select between the available conf files
> even with hierarchy.

Interesting approach. But in Fedora, we want to default to:
1. the x86_64 -devel package if only it is installed,
2. the i686 -devel package if only it is installed (even on an x86_64
   system),
3. the x86_64 -devel package if both i686 and x86_64 are installed.
How to set QTCHOOSER_GLOBAL_DIR while honoring 2. is non-obvious.

> I think the biggest issue here for us Debian are executables called at
> runtime for which no claim for backward compatibility was made. As
> binaries where not prefixed we needed to set qt4 as default to not break
> the user's setups (and here I mean the user of the apps made with Qt).

On Fedora, qdbus is always the Qt 4 version (unless the user sets up 
qtchooser, but then it's really not our problem), the Qt 5 version is
qdbus-qt5. Where Qt 5 stuff is calling just qdbus, it will need to be fixed. 
(We are already looking into fixing our copy of startkde, I am planning to 
just replace it entirely with a forked version in the Fedora package, as I 
already did for the startkde in kde-workspace 4 after we were hit by yet 
another regression triggered by an unwanted upstream startkde change.)

> Maybe in these cases the real solution would be simply adding the prefix
> *or* specifying in the docs that it must be called with the -qt<foo>
> argument, and consider a bug when that's not done. But as qtchooser was
> not really deployed in other OSs I don't know how practical this can be.

Indeed, documenting to use the -qt* argument is not a good idea, qtchooser 
is not really used outside of Debian.

        Kevin Kofler