[Development] Qt 6 co-installability with Qt 5

[Kevin Kofler]

Shawn Rutledge wrote:
> If distro maintainers insist that /usr/bin/qml must be an executable and
> not a symlink

Fedora used to ship symlinks for the suffixed Qt binaries in /usr/bin/
(pointing to the relevant Qt version). Fedora switched to hardlinks instead 
because:
* Symlinks pointing, e.g., /usr/bin/moc-qt5 → /usr/lib64/qt5/moc cause
  multilib conflicts because the 32-bit version will want the symlink
  pointing to /usr/lib/qt5/moc instead, and symlinks are not supported by
  the ELF coloring mechanism RPM uses to prevent multilib conflicts. Hence
  Fedora quickly switched to reversed symlinks:
* Reversed symlinks (/usr/lib64/qt5/moc → /usr/bin/moc-qt5) solve the
  multilib problem (RPM will prefer the 64-bit binary and /usr/lib/qt5/moc
  will also point to the 64-bit binary, which works as long as both come
  from the same version of Qt), but it was found that those symlinks confuse
  qtchooser. Since some Fedora maintainers wanted to support qtchooser
  optionally (using the "separate directory for qtchooser wrappers that you
  have to manually prepend to PATH" approach), that was also no longer an
  option.

Hence, the switch to hardlinks, which worked around both problems. But 
distro maintainers are definitely not opposed to symlinks if and where they 
work.

> then I guess it should be the Qt 6 version

I object. The unsuffixed executable, if installed, needs to point to the 
oldest version for backwards compatibility. And everything should switch to 
using the suffixed versions only.

> to go along with the fact that we’re pushing the open source community
> pretty hard to upgrade as soon as it’s released.

But realistically speaking, Qt 5 is not going away any time soon. I still 
use some Qt 3 (!) programs. I am also sending this message with a Qt 4 
program (KNode).

        Kevin Kofler