[Development] Qt 6 co-installability with Qt 5

[Kevin Kofler]

Shawn Rutledge wrote:
> I get the impression qtchooser is not popular among distro maintainers; in
> 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.)

The reason it is not popular among distro maintainers is that, while the 
approach may make sense to someone only compiling their own projects, as 
soon as you need to compile someone else's software, you realize that 
qtchooser's way of working does not match reality.

The thing is, most software projects need a specific major version of Qt to 
compile, and different software projects need different versions of Qt. So, 
what do you think makes more sense from the user's point of view:
a) the user needs to look up in the software's documentation which version
   of Qt it expects, and manually configure qtchooser to point to that
   version of Qt to get the software to compile, OR
b) the build system, which *knows* which version of Qt is needed, simply
   invokes the correct version-suffixed Qt binary and everything just works
   for the user with no manual setup needed
?

I would clearly choose option b. And while there is some support for a setup 
like this in qtchooser (build systems can override the configured choice of 
qtchooser by passing command-line arguments to the tools), that support is 
more of an afterthought and has a major design flaw: if the tool is not 
actually being wrapped by qtchooser, the build system will attempt to pass 
arguments meant for qtchooser directly to the tool, and the tool will choke 
on those arguments. Hence, it is not a portable mechanism. (I have had to 
sed -i -e 's/qmake -qt5/qmake-qt5/g' (or moc-qt5 etc.) in more than one 
upstream project's build system when packaging, to get it to build at all.)

The suffixed binaries, which have been used by distros for years and which 
are now finally being officially adopted in Qt 6, solve this nicely and 
cleanly: qmake-qt6, if it exists, is always QMake from Qt 6. The build 
system of software developed for Qt 6 just needs to call this binary and 
will get the QMake from the correct version of Qt without requiring any 
magic command-line arguments to a wrapper that may or may not actually be 
installed. And likewise for the other tools with version suffixes. And now 
that the suffixes are officially supported, build systems no longer need to 
support all the much more complicated competing setups (such as qtchooser).

> 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.

Well yes, if you want to use qtchooser, that is the way to go. I do not see 
why you need distro support for it, given that you can easily set it up that 
way if you absolutely need this tool (with all its limitations).

> 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?

Several things are wrong with this idea, in particular:
1. As you point out with your question below, this is a system-wide
   mechanism, requiring root permissions to select the version of Qt.
2. The choice is a global system state, so one cannot compile software
   requiring different versions of Qt in parallel.
3. As pointed out above, the user should not have to select a version of Qt
   to begin with, that is the job of the build system of the software the
   user is trying to compile, which *knows* what version of Qt it needs.

> (Is there a user-specific alternative?)

There are environment modules, but they also suffer from issue 3 above, and 
to some extent from issue 2 (though with environment variables, you can at 
least runtime-override the global selection locally within a shell).

Really, it is this whole concept of the user choosing a version of Qt that 
is flawed. The right place to make this choice is the build system of the 
software using Qt.

> 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?

Once compiled, usually yes, but you need to compile them first. Unless you 
use the distro packages, in which case the distro needs to compile the 
applications for you, and as a distro packager, I can tell you that anything 
that requires me to "select" a Qt version is extra boilerplate I do not want 
in my package specfiles.

Distro packages need to compile on systems with more than one version of Qt 
installed. (Technically, most distros build the production packages in 
chroots containing only the explicitly listed build requirements, which will 
in most cases include only one version of Qt, but a well-designed package 
ought to also build locally in a full, non-chroot system.) A few distro 
packages also need to compile different parts against different versions of 
Qt, at once. (E.g., poppler has bindings for multiple versions of Qt, so the 
package needs to install them all at build time to build the subpackages for 
the different bindings.) Anything that requires explicitly selecting a 
specific version of Qt in that situation is just extra boilerplate that is 
absolutely avoidable, because the software being built already *knows* which 
version(s) of Qt it needs.

> 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.

If any changes are needed to make qtchooser work with Qt 6, then I suggest 
that those like you who want to keep using it fork it and make those 
required changes. It is Free Software.

> 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.

The anti-pattern there is really that you as the user have to pick the 
version of Python at all. The Python scripts ought to have the correct 
#!/usr/bin/env python2 or #!/usr/bin/env python3 shebang. (There too, the 
script *knows* which version of Python it needs and ought to just work.)

Can you also use shebangs for QML? (If not, then the interpreter ought to be 
fixed to allow them, it just needs to ignore the shebang line if it is not 
already treated as a comment.)

> And I hope our transition is not going to take as long as that one has,
> either. ;-)

I think it will take longer. ;-) I still use some software using Qt 3!

        Kevin Kofler