[Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 16 Feb 2021 at 11:37, Ville Voutilainen
<ville.voutilainen at gmail.com> wrote:
>
> 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.

Exactly, and that's because you have both python2 and python3
executables on path.

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

And again, exactly. So comparing against Python on Windows is, as you
say, and apples-and-oranges comparison.

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

And in fact we can use python (again) as a good example: let the
user-facing binaries have the major version in them. And this time the
comparison is on Linux, where it belongs.

Kai: we the maintainers have been asking for the right solution since
the Qt3 to Qt4 switch. For a developer having to add the "6" after the
tool, while it might be a change, it will pretty sure be
straightforward. And by doing this we fix the issue not only for this
release but for every major release here upon.

Tip: many Linux users expect qmake6 or some other variant to call
qmake. Now it's time to make it official *and* consistent for
everyone.