[Development] Qt6/Qt5 coinstallability (Linux distributions)

[Lisandro Damián Nicanor Pérez Meyer]

Hi! I would like to bring this issue with time so we can try to find a nice
solution for this.

Some time before Qt5 was released, in an attempt for Qt4/Qt5 coinstallability,
qtchooser was developed to help ensure e.g. moc, qdbus and rcc could coexist.
Before qtchooser came in a user could not have the same tool installed at the
same time for both versions, or would have to put them in another place other
than /usr/bin or [insert any other possible solutions here].

qtchooser was kind of adopted by only half the linux distributions out there,
and even if it served it's purpose it has it's own share of [bugs] that are
either hard to fix, or even impossible by design.

So I propose that for Qt6 we try to think in a different approach; an approach
that maybe needs to be thought from the beginning, and I think this is the
right time to start with this.

Maybe the simplest one is to just introduce version numbers to all those
executables: uic6, qml6, rcc6 (or some variations of that uic-6, uic-qt6...)
But we are open to other ideas.

Much as Thiago did for the build system thread, I would like to share my
thoughts on what would be ideal to get accomplished:

a) Qt 5 and Qt 6 binaries should be coinstalable both in a developer
(libraries + binaries + build tools) and in a user's (only required libraries
and binaries) perspective. For example: a user should not need qmake to be
present.

b) There should be no need to become root in order to switch between Qt
versions.

c) Ideally no "proxy" executable should be used.

Again, we are open to other ideas.

Thanks in advance.

[bugs] <https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser>

[Thiago Macieira]

On Tuesday, 13 November 2018 13:43:20 PST Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer
a) Qt 5 and Qt 6 binaries should be coinstalable both in a developer
(libraries + binaries + build tools) and in a user's (only required
libraries and binaries) perspective. For example: a user should not need
qmake to be present.

This does not apply for "application" executables that retain backwards
compatibility functionality. There's no need to version linguist, designer,
assistant or qdbus, qdbusviewer, so long as those applications can still be
used while developing Qt 5 applications.

The other extreme are development tools that almost never need to be run
directly by directly the user, at all. That's the case for rcc, uic, moc,
lupdate, lrelease, qmlcachegen, etc. Those should not be in the $bindir in the
first place: they should live in $libexecdir and ought to be found by way of
the .cmake and .pc files, as in:
pkg-config --variable=libexecdir Qt6Core

That only leaves front-end tools that are intricately tied to the Qt version
that need renaming. The only two I can think of that fits this description are
the "qml" and "qmlscene" pair. If we're feeling nice, we can do it too for
diagnostic tools, like qtdiag, qtpaths, qtplugininfo.

And then there's qmake. I'd really love if it were a backwards-compatible tool
that worked for both Qt 5 and 6. It's unlikely to happen, since choosing the
Qt version has always been done by selecting the proper qmake. So I imagine it
will be one of the renamed ones.

$ ls -1 `qmake -qt5-installed -query QT_INSTALL_BINS`
assistant
canbusutil
designer
fixqt4headers.pl
lconvert
linguist
lrelease
lupdate
moc
pixeltool
qdbus
qdbuscpp2xml
qdbusviewer
qdbusxml2cpp
qdistancefieldgenerator
qdoc
qgltf
qhelpgenerator
qlalr
qmake
qml
qmlcachegen
qmleasing
qmlimportscanner
qmljs
qmllint
qmlmin
qmlplugindump
qmlpreview
qmlprofiler
qmlscene
qmltestrunner
qscxmlc
qtattributionsscanner
qtcreator
qtcreator.sh
qtdiag
qtpaths
qtplugininfo
qtwaylandscanner
qvkgen
rcc
repc
sdpscanner
syncqt.pl
uic
xmlpatterns
xmlpatternsvalidator

[Lisandro Damián Nicanor Pérez Meyer]

Post by Thiago Macieira
On Tuesday, 13 November 2018 13:43:20 PST Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer
a) Qt 5 and Qt 6 binaries should be coinstalable both in a developer
(libraries + binaries + build tools) and in a user's (only required
libraries and binaries) perspective. For example: a user should not need
qmake to be present.

This does not apply for "application" executables that retain backwards
compatibility functionality. There's no need to version linguist, designer,
assistant or qdbus, qdbusviewer, so long as those applications can still be
used while developing Qt 5 applications.

Agreed, but this means that if an application is backwards compatible then it
must be kept like that for all the Qt 6 lifetime. Is that feasible?

And I could even stretch it a little more, at least just "for the fun of it":
it might also mean to keep backwards compatibility in Qt n with n > 6. Why?
Because some libs that depend on Qt need to be built with any Qt versions
still present on a user's system. While having new Qt 4 applications nowadays
is strange we still have lots of them to maintain (I can give figures/examples
if needed).

But again, I might be stretching it too much. Or not.

Post by Thiago Macieira
The other extreme are development tools that almost never need to be run
directly by directly the user, at all. That's the case for rcc, uic, moc,
lupdate, lrelease, qmlcachegen, etc. Those should not be in the $bindir in
the first place: they should live in $libexecdir and ought to be found by
pkg-config --variable=libexecdir Qt6Core

Exactly.

Post by Thiago Macieira
That only leaves front-end tools that are intricately tied to the Qt version
that need renaming. The only two I can think of that fits this description
are the "qml" and "qmlscene" pair. If we're feeling nice, we can do it too
for diagnostic tools, like qtdiag, qtpaths, qtplugininfo.

It would probably be the safest thing to do.

[Thiago Macieira]

On Tuesday, 13 November 2018 15:19:58 PST Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer
Agreed, but this means that if an application is backwards compatible then
it must be kept like that for all the Qt 6 lifetime. Is that feasible?

Yes. Assistant, Linguist, the D-Bus tools should be.

But I've just remembered that Designer loads plugins and those are quite
clearly tied to the Qt version. The file format is backwards compatible and
has remained so for a few years. It is possible that the plugins generate the
same XML regardless of version, but I think we shouldn't risk it. So yes,
Designer should be versioned.

Post by Lisandro Damián Nicanor Pérez Meyer

Post by Thiago Macieira
That only leaves front-end tools that are intricately tied to the Qt
version that need renaming. The only two I can think of that fits this
description are the "qml" and "qmlscene" pair. If we're feeling nice, we
can do it too for diagnostic tools, like qtdiag, qtpaths, qtplugininfo.

It would probably be the safest thing to do.

[Kevin Kofler]

Post by Thiago Macieira
But I've just remembered that Designer loads plugins and those are quite
clearly tied to the Qt version. The file format is backwards compatible
and has remained so for a few years. It is possible that the plugins
generate the same XML regardless of version, but I think we shouldn't risk
it. So yes, Designer should be versioned.

I think it would be much safer to just version everything.

Just remember Assistant in Qt 4, where early 4.x releases shipped an
Assistant that was essentially compatible with the Qt 3 version, but it was
later renamed to assistant_adp (and later dropped from the Qt distribution
and shipped as an unmaintained separate legacy tarball) and a new
incompatible Assistant (the QCH one) was introduced.

Kevin Kofler

[Thiago Macieira]

Post by Kevin Kofler

Post by Thiago Macieira
But I've just remembered that Designer loads plugins and those are quite
clearly tied to the Qt version. The file format is backwards compatible
and has remained so for a few years. It is possible that the plugins
generate the same XML regardless of version, but I think we shouldn't risk
it. So yes, Designer should be versioned.

I think it would be much safer to just version everything.
Just remember Assistant in Qt 4, where early 4.x releases shipped an
Assistant that was essentially compatible with the Qt 3 version, but it was
later renamed to assistant_adp (and later dropped from the Qt distribution
and shipped as an unmaintained separate legacy tarball) and a new
incompatible Assistant (the QCH one) was introduced.

Ok, so two categories only:
1) applications run by the user (in bin, versioned)
2) applications run only during build (in libexec, unversioned)

[Lisandro Damián Nicanor Pérez Meyer]

[snip]

Post by Thiago Macieira

Post by Kevin Kofler
I think it would be much safer to just version everything.
Just remember Assistant in Qt 4, where early 4.x releases shipped an
Assistant that was essentially compatible with the Qt 3 version, but it was
later renamed to assistant_adp (and later dropped from the Qt distribution
and shipped as an unmaintained separate legacy tarball) and a new
incompatible Assistant (the QCH one) was introduced.

1) applications run by the user (in bin, versioned)
2) applications run only during build (in libexec, unversioned)

I would of course agree here. But so far only three of us participated in this
thread, so I would like to ask:

a) Is there something else I could do to make this a consensus decision? Or
maybe do something to make this the roadmap for Qt 6?

b) If at some point we can agree it has been decided, is there any way I could
start contributing code in order to achieve this? Maybe I should just wait
until the new build system is on stage? something else?

Cheers, Lisandro.

[Thiago Macieira]

On Monday, 19 November 2018 11:42:48 PST Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer
b) If at some point we can agree it has been decided, is there any way I
could start contributing code in order to achieve this? Maybe I should just
wait until the new build system is on stage? something else?

Since it's a Qt 6 thing, it should happen with the buildsystem, which means we
need to actually decide on which one to use. Even though it currently looks
there's only one in contention, it's not a *decision*.