[Development] Qt6/Qt5 coinstallability (Linux distributions)

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 13 de noviembre de 2018 19:56:29 -03 Thiago Macieira escribió:
> On Tuesday, 13 November 2018 13:43:20 PST Lisandro Damián Nicanor Pérez
> Meyer
> wrote:
> > 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.

> 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

Exactly.

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


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181113/820a8a51/attachment.sig>