[Development] Qt 6 co-installability with Qt 5

[Lars Knoll]

On 18 Nov 2020, at 00:41, Lisandro Damián Nicanor Pérez Meyer <perezmeyer at gmail.com<mailto:perezmeyer at gmail.com>> wrote:

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
Have we fixed it?

I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
binary with the same name as Qt 5 did.

Lars and I just had a quick discussion on IRC about this and here's what we
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not
most users. For us, setting PATH is acceptable. We're also likely the only
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
recommendation allows Linux distributions to apply workarounds meanwhile,
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
 (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

Thinking a bit more about this, I wonder how many applications _really_ need a version.

To start with, I think it’s important to recognise a difference between developer oriented tools and tools targeting end users.

Most of our developer oriented tools are (or can be) dependent on the exact version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 thing.

Those tools should just stay in a version specific directory and should IMO not be exposed in the generic path for end users (moc should for example never end up in /usr/bin). Instead the correct version is found by the build system and called from there. And developers needing direct access to them should adjust their path to include those tools.

For most end user facing tools, I wonder whether we actually need to support co-installation. The examples listed just below (linguist etc.) are backwards compatible, and it should be ok to simply install the latest version, similar to what is done with qtcreator.

Once we have that, the question is what is left that actually has to have a versioned name?


The question is what tools are those in lists (b) and (c). Starting with the
easiest (c):
- linguist
- qdbus
- qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's
up to the implementer to decide which Qt version they want these tools to be
and any choice is fine. My guess is that for two of the three, it will depend
mostly on Look-and-Feel with the desktop. But since these are an implementer's
choice, Qt installation never installs those tools with the unsuffixed names
by default.

Agreed to all above.

Then there's the question of which tools we recommend be in $PATH with a
suffix (list (b)). Please expand on this list if necessary, with a reason.
Here's the minimum list:

qmake6         entry point for building qmake-based applications, situation
               similar to /usr/bin/python (see [1])

I am not yet 100% convinced it is. This is a build tool after all, and even changes with minor versions of Qt. I know Linux distributions do only ship one minor version, but many of our users have to manage multiple minor versions of Qt as well. And renaming qmake with every minor version is a no-go.

qml6           I don't understand why, but I'm told it's necessary

It’s a runtime for running qml files without a C++ entry point. But we can actually decide that this is a developer oriented tool and not have it linked into /usr/bin.

qtdiag6        entry point for debugging problems with Qt 6
qtpaths6       because knowing the path in order to run the tool to get
               paths sounds weird. Having this in $PATH allows us to
               help users get to the other, debugging tools (qtplugininfo,
               qmlplugindump, etc.)

Possibly also:

assistant6     for reading Qt 6 help files when not using Qt Creator
designer6      for those not using Qt Creator and needing to use Qt 6 plugins

Offtopic, but I wonder how much those standalone apps are still being used today.

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as above

- sdpscanner: "Performs an SDP scan on remote device, using the SDP server
represented by the local Bluetooth device." Sounds like a user-facing app.

All of those are developer facing tools and shouldn’t be in /usr/bin at all IMO.

Cheers,
Lars




--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201118/d03f1f38/attachment-0001.html>