[Development] Qt 6 co-installability with Qt 5
thiago.macieira at intel.com
Mon Nov 2 17:15:34 CET 2020
On Monday, 2 November 2020 06:21:49 PST Shawn Rutledge wrote:
> Sorry for snipping so much, but it seems like all your arguments are about
> tools that are used to build software (qmake, moc etc.). And you have a
> point there.
> 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.
I made a list of which tools are user-facing and which ones are development.
Of those in your list, I only agree with for assistant. And I add qdbus and
qdbusviewer. A requirement for "user-facing" implies that the tool performs
the same task without loss of functionality if it was upgraded.
qml is like Python: because of plugins, it's tied to the Qt version.
Therefore, it fails the requirement for supporting everything the old version
supported. Therefore, like Python, it requires a version number.
qtdiag is VERY much about the Qt version: you want to diagnose why a specific
Qt version is having the issues it is, so it should have the suffix and the Qt
5 version should be allowed to be present if it is installed. Like it, I'd
like to have qplugininfo installed in the developer's system, so one can ask
for information from it when debugging issues; and like qtdiag, it needs a
On pixeltool I can't comment because I've NEVER EVER run it, I don't know what
it does and it's not even installed on my system.
> When it comes to the actual suffix to add, why use -qt6 instead of just 6?
KDE Frameworks 5 tools added just a "5" so it's fine:
$ ls -1 /usr/bin/k*5
Since they're likely to repeat the procedure for a Qt 6-based Frameworks, we
could standardise on just "6" as a suffix too.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
More information about the Development