Resending because I mistakenly replied just to Lars. Lars: thansk for the heads up, and also note I rewrote a paragraph below, hopefully to be more on point.
On 19/06/11 07:12, Lars Knoll wrote: > Hi Lisandro, Hi Lars! [snip] > That thread doesn’t explain why qtchooser isn’t a solution. It does work > without problems for all my use cases, and I certainly do have quite a few Qt > versions installed in parallel. Maybe my fault, I have discussed this in this mailing list before. The mail also has a link to our bugs list, but let me try to write down it's pros and cons here. > Part of the problem simply stems from the fact that Linux distributions > want to put all the binaries into /usr/bin. As long as you keep separate > Qt versions in separate directories there’s no problem I know of. Each operative system has it's design rules. We might or not like them, but if we want Qt to be really a multi-platform code-once tool then we should accept those rules and do our best to build upon them. Let's try to put this into two three different points of view: - A Qt-internals' developer - A developer using Qt to create stuff - A system developer/integrator (within this, distro maintainers). > Giving our build tools different names depending on the version can create > other problems for our users, especially those that use some hand rolled > build systems (and we probably have lots of those as well). And the above is clearly a thing a Qt-internals' developer should definitely look to, so a very valid concern. But let's take the other's too. I am taking maybe another approach to what Kevin already wrote in [a], but I do agree to what he wrote there too. [a] <https://lists.qt-project.org/pipermail/development/2019-June/036453.html> # Problem 1: binary masking At first I thought qtchooser might probe to be a nice tool for switching versions much like Shawn wrote, but then experience showed us the contrary. With "binary masking" I mean that qtchooser replaces the path for where a binary should be with itself. With this comes the following cases: ## Binaries that need to be accesible by "the user" This are the ones that really need to be in $PATH because the normal user needs it. We can't expect a normal user to add to $PATH a "weird" path of a specific Qt version and change it every time it needs to switch versions. Let's add that the user of that application might well be another application or system library. We can list qdbus and qdbusviewer as examples (perhaps not the best ones, but will do for now). So let's say app4 is compiled against Qt4 (we still have them around, sadly not every useful app was yet ported) and app5 is compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where developed using their own version's qdbus in mind. As a packager my duty is to ensure that app4 has a strong dependency against Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both versions of qdbus will be installed. Now both app4 and app5 developer's will probably not worry about qtchooser because it's just a hack needed on Linux, so they won't be calling 'qdbus -qt5' (which, as Kevin said, it's not even a standard) but just 'qdbus'. So with qtchooser around app4 and app5 will receive both the same version of qdbus, be it Qt 4's or 5's. So, why it has not backfired yet? Because thanks Thiago (probably) qdbus behaves the same in both Qt 4 and 5. Had they differed in the way they behave... kaboom. We packagers would be probably needed to start patching applications to pass proper qtchooser arguments, which is not something developers that use Qt like a lot. So the big question here is: can we *really* keep this applications backward-compatible for the whole Qt 4, 5 and 6 and future versions? ## Binaries that need to be accesible by developers using Qt These are moc, rcc, linguist, designer, uic, etc. Some of them really need to be in $libexecdir and ought to be found by way of the .cmake and .pc files [1]. But then there are the other tools that, once again, need to be readily accesible for a developer user but in a much "normal" way. Let's say for example linguist. Translators are normally more in the "user" side of things than in the "developer" side. assistant might probably be in this situation too. [1] <https://lists.qt-project.org/pipermail/development/2018-November/034382.html> [2] <https://lists.qt-project.org/pipermail/development/2018-November/034385.html> And maybe lupdate is also an elegible example. ## Binary masking and dependency resolution Now the user installs qt5's qdbus. Currently that will in turn install qtchooser (there is currently no way around it except renaming binaries), so /usr/bin/qdbus is taken. Now the user needs qt5's qdbus, so he simply runs 'qdbus'. It will fail. Why is that? Because in Qt 4 the concept of qtchooser did not exist, so the default system consiguration needs to be qt4 as long as there is any piece of it installed on the system. So the user thinks it's a qdbus bug, but it's actually a bad dependency resolution due to qtchooser. Note that this example is also valid in the Qt 4 case and will be in the Qt 6 case too because developers of Qt solutions do not take qtchooser into account, so they won't be calling "qdbus -qtfoo" from within their apps. And that's what Qt has told us all this time: "Code less, create more, deploy everywhere". Now if we switched user-facing binaries to say qdbus6 the above motto would still be true for all aps written with Qt 6. # Problem 2: masks user-facing applications that belong just to one specific version The easy example here is qtconfig. Right, one could easily say "hey, just let /usr/bin/qtconfig be a symlink to qt4's $libexec's qtconfig". But then what would happen with a tool that ships in Qt 4 and 5 but not in Qt 6? This is exactly Debian bug <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764184> # Seeing the problem as a Qt-internal's developer I can see value in qtchooser for Qt-internal's developers. You can easily switch between Qt versions without too much hassle. I sincerely do not know how you manage to keep up with your desktop environment in Linux as I'm pretty sure most of you are not using a GTK-based desktop :-) Why I say that? because even the smallest Qt-based desktop environment ships theming which requires using Qt's private API, so it's tightly tied to a specific ¡minor! version. And I'm pretty sure there are other cases which have the same issue. But let's go back to Lars' original mail, rewriting here for speeding up things: > Giving our build tools different names depending on the version can create > other problems for our users, especially those that use some hand rolled > build systems (and we probably have lots of those as well). This is comparable to people not using CMake, qmake or qbs to build Qt based applications/libraries. If they do things by hand then they must understand beforehand that things might break. Note that even Qt-generated pkgconfig files had issues that took quite long to fix. With this I want to emphasize that the *trully* supported build systems are qmake, CMake and qbs, be it by Qt Co., any other company or the community. # Proposed solution All user-facing binaries that do not really belong to $libexec should be suffixed, as explained in <https://lists.qt-project.org/pipermail/development/2018-November/034386.html> - For integrators it will mean easily-deployable solutions without hacks. - For Qt-internal's developers will certainly not affect them much once they get used to the switch (yes, I understand a change sometimes brings discomfort). - For developers using Qt it means they will directly understand that the specific user-faced tool is *specific* to the Qt version and it might change in future releases. **Pretty please** be sure to state if there is another thing I did not consider. I'm pretty sure we can work out viable solutions. Cheers, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
