[Development] Qt 6 co-installability with Qt 5

Kevin Kofler kevin.kofler at chello.at
Mon Nov 2 16:42:06 CET 2020


Shawn Rutledge wrote:
> But I don’t see the point of renaming user-facing tools like assistant,
> qml, qtdiag and pixeltool.   So I hope at least those will be spared.

At least assistant is frequently invoked by software and hence should 
definitely be officially suffixed so that software stops accidentally 
invoking the wrong version of assistant.

> When it comes to the actual suffix to add, why use -qt6 instead of just 6?

Because that's the naming scheme distros have been using for years.

(That said, I do not care strongly about it as long as there is SOME 
suffix.)

> BTW java still works without having to add some clumsy suffix. 
> /usr/bin/javac -> /usr/lib/jfm/default/bin/javac for example.  I can see
> which version it is with the -version argument.  I guess there aren't
> enough compatibility breaks to justify suffixing?  But we are also trying
> to avoid it.

Actually, several of us distro people consider the Java alternatives setup 
to be the "clumsy" one and see this as an antipattern to not follow. (I 
definitely do.)

The main reason this evolved this way at all was because the official Java 
used to be proprietary, and the Free Software Java stack shipped in distros 
used to always lag behind the proprietary reference implementation's 
functionality, so there was the need to easily let users switch to the 
proprietary implementation. Now that we have OpenJDK, many packagers 
consider this setup historical and obsolete and want to get rid of it, but 
selecting the version of OpenJDK is the one use case that keeps it alive.

But for the same reasons as for Qt, alternatives is also a poor approach for 
Java, because it is system-wide (and hence requires root permissions) and 
global (breaking concurrency). Suffixed binaries would actually be more 
practical, and it has been done both for compilers (e.g., for GCC) and for 
inerpreters (e.g., for Python), so why not for javac and java?

Thus, I do not see the Java alternatives setup as a good example to follow, 
sorry.

        Kevin Kofler



More information about the Development mailing list