[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