[Development] Qt 6 co-installability with Qt 5

Shawn Rutledge Shawn.Rutledge at qt.io
Wed Oct 28 12:05:25 CET 2020



> On 27 Oct 2020, at 20:33, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Tuesday, 27 October 2020 10:06:32 PDT Shawn Rutledge wrote:
>>> On 27 Oct 2020, at 17:34, Thiago Macieira <thiago.macieira at intel.com>
>>> 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.
>> 
>> 
>> Well I still use it for Qt 6.  It works fine, but I suppose we’ve added some
>> new binaries that need symlinks.
> 
> No symlinks necessary.

I meant the symlinks pointing to qtchooser, for people who use it.

Otherwise I’m not sure what you meant about “not updating” qtchooser.

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

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.

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



More information about the Development mailing list