> On 27 Oct 2020, at 20:33, Thiago Macieira <[email protected]> wrote: > > On Tuesday, 27 October 2020 10:06:32 PDT Shawn Rutledge wrote: >>> On 27 Oct 2020, at 17:34, Thiago Macieira <[email protected]> >>> 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. ;-) _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
