[Development] Qt 6 co-installability with Qt 5

[Ville Voutilainen]

On Tue, 16 Feb 2021 at 15:35, Kai Köhne <Kai.Koehne at qt.io> wrote:
> And again, this is not something limited to Qt. Last time I checked, the executable to run Python 3 on Windows is python.exe, not python3.exe. On Debian at least it's python3. This hasn't blocked Python from being perceived as overall beginner friendly ...

Uh.. that seems like an apples-and-oranges comparison. On linux, it's
expected and conventional that if you install both
python 3 and python 2, both are available in the usual PATH, neither
eclipses the other, and you can cd between python 2
and python 3 projects and run both, without switching environments or
alternatives in between.

On windows, I don't know what's conventional. In many cases, a
shortcut is used that launches a command prompt
with the right environment, and using two versions in the same command
prompt just isn't done.

> So, I would stick to qmake as canonical name, also in the documentation. We can mention that it's sometimes called qmake6 on Linux. But forcing everyone to change their habit and scripts just for the sake of consistency with a fraction of the users that use a global installation on Linux, and do not use update-alternatives, is IMO not a good move.

update-alternatives is a long-term system-wide configuration change.
Changing PATH is a shorter-term user-specific one. That's how I switch
between compilers, and I wouldn't dream of using update-alternatives
to switch between them. Especially not
on multi-user systems, where it's none of my business to change the
alternative used for a system compiler
for other people. I *can't* do an update-alternatives on a build
server, and I *shouldn't*. That doesn't mean that
a build server installation couldn't have both qt 5 and qt 6 installed
in a system-wide location.

Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
If our approach requires it, our approach
is broken.