[Development] Qt 6 co-installability with Qt 5
kevin.kofler at chello.at
Sun Nov 1 01:19:10 CET 2020
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
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!
More information about the Development