[Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 28 October 2020 04:05:25 PDT Shawn Rutledge wrote:
> I meant the symlinks pointing to qtchooser, for people who use it.
> 
> Otherwise I’m not sure what you meant about “not updating” qtchooser.

qtchooser manages the symlinks. I don't want to update qtchooser, which means 
I don't want to add the new set of symlinks.

> > Either all Qt binaries get installed into the libdir 
> > and are not accessible via $PATH, or they all get a "-qt6" suffix.
> 
> I get the impression qtchooser is not popular among distro maintainers; in

Correct, it isn't. We must move away from it. The solution for Qt 6 must not 
depend on it.

So here's the problem statement: assuming all Qt 5 binaries are already 
installed in CMAKE_INSTALL_BINDIR (/usr/bin), install Qt 6 without replacing 
any file that is already there. The same applies to any libraries, plugins, 
and CMake files, but those already have a different name.

> practice it’s mainly been up to people who want to be able to switch
> quickly and often between qt versions to install it themselves. (There was
> a period when Arch had it; then they took it away again.)  Consequently I
> have to install the symlinks pointing to qtchooser into some place that
> comes earlier in the path than /usr/bin, and it’s easier if that is a
> location where I don’t need sudo to make the links either.  Usually I have
> /usr/local/bin and ~/bin both coming earlier in my PATH, so installing
> qtchooser in either of those is OK for me.  But I’m open to better ideas.

Which tools do you often run manually? I find that I only run:
* qdbus
* qmake
* qplugininfo
* qtdiag

I don't run these but I suspect other people do:
* assistant
* designer
* linguist
* qtpaths
* qml & qmlscene

And of those, qmake is by far the most common, by at least 10x compared to the 
second place.

All of the rest are development tools only. I've run moc manually in the past, 
but that's when I was checking what output it produced.
 
> On Debian there’s /etc/alternatives, so what’s wrong if Qt binaries get
> installed into some location that’s not in the PATH, the /usr/bin symlinks
> point to Qt 6 binaries by default (via /etc/alternatives on distros that
> have it), and then you switch Qt versions with the standard distro
> mechanism?  (Is there a user-specific alternative?)  Meanwhile,
> applications that need Qt 5 link against Qt 5 libs (different mechanisms
> might apply), and don’t necessarily need any Qt-installed binaries from
> PATH, right?  And those who want to install qtchooser just need to set up
> its config files if the distro doesn’t provide them; it works with any lib
> path and any binary path, but can’t deal with binaries being renamed
> AFAIK.

Because Debian Alternatives are a system-wide configuration and requires one 
to be the superuser to apply. This is what qtchooser attempted to fix, by 
making it entirely under the control of a user and modifiable with just the 
environment. So Alternatives is not a solution.

We need an answer to the problem statement as posed above.
 
> In any case I don’t particularly want to need to type “qml6” on the command
> line to run the qml interpreter, if it can be avoided.  When I think about
> how often I have had to switch the python symlink to point to either
> python2 or python3 because of some script that made an assumption or was
> written before python3 existed: that’s an anti-pattern IMO.  And I hope our
> transition is not going to take as long as that one has, either.  ;-)

Unfortunately, you will have to because the plugins are different. QML is not 
a scripting language, you cannot assume that the plugins that exist for QML on 
Qt 6 are present in the plugins that exist on QML for Qt 5. This is also the 
reason why Qt Designer needs a different name too.

For the sake of muscle memory, Qt installation may add unsuffixed binaries 
elsewhere in the system, allowing you to modify $PATH. But to 
CMAKE_INSTALL_BINDIR you cannot install any binaries that Qt 5 already has.

The only tools that are truly version-independent are qdbus and Linguist. All 
the rest are tied to the specific Qt version.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering