[Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
> Have we fixed it?
> 
> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
> binary with the same name as Qt 5 did.

Lars and I just had a quick discussion on IRC about this and here's what we 
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not 
most users. For us, setting PATH is acceptable. We're also likely the only 
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for 
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This 
recommendation allows Linux distributions to apply workarounds meanwhile, 
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools, 
which I have not followed and do not understand the current state of. Need 
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
  (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

The question is what tools are those in lists (b) and (c). Starting with the 
easiest (c):
 - linguist
 - qdbus
 - qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's 
up to the implementer to decide which Qt version they want these tools to be 
and any choice is fine. My guess is that for two of the three, it will depend 
mostly on Look-and-Feel with the desktop. But since these are an implementer's 
choice, Qt installation never installs those tools with the unsuffixed names 
by default.

Then there's the question of which tools we recommend be in $PATH with a 
suffix (list (b)). Please expand on this list if necessary, with a reason. 
Here's the minimum list:

 qmake6		entry point for building qmake-based applications, situation
		similar to /usr/bin/python (see [1])
 qml6		I don't understand why, but I'm told it's necessary
 qtdiag6	entry point for debugging problems with Qt 6
 qtpaths6	because knowing the path in order to run the tool to get 
		paths sounds weird. Having this in $PATH allows us to
		help users get to the other, debugging tools (qtplugininfo,
		qmlplugindump, etc.)

Possibly also:

 assistant6	for reading Qt 6 help files when not using Qt Creator
 designer6	for those not using Qt Creator and needing to use Qt 6 plugins

We may want to have more suffixes and more stubbing, symlinking, such as what 
exists for LLVM in some distros:

lrwxrwxrwx 1 root root 14 nov  3 02:54 /usr/bin/clang++-10 -> clang++-10.0.1
lrwxrwxrwx 1 root root 14 nov  3 02:54 /usr/bin/clang++-10.0 -> clang++-10.0.1
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang++-10.0.1 -> clang-10.0.1
lrwxrwxrwx 1 root root 14 nov  2 07:58 /usr/bin/clang++-11 -> clang++-11.0.0
lrwxrwxrwx 1 root root 14 nov  2 07:58 /usr/bin/clang++-11.0 -> clang++-11.0.0
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang++-11.0.0 -> clang-11.0.0
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang-10 -> clang-10.0.1
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang-10.0 -> clang-10.0.1
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang-11 -> clang-11.0.0
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang-11.0 -> clang-11.0.0

Note: LLVM is NOT a good example in most ways. I do know OpenSUSE heavily 
patches the LLVM build to get reasonable library names, CMake files and 
binaries. I did the same in [2].

[1] https://www.python.org/dev/peps/pep-0394/
[2] https://github.com/clearlinux-pkgs/llvm9/blob/master/install_append
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering