<div dir="auto"><div>Ping?<br><br><div class="gmail_quote"><div dir="ltr">El sáb., 4 de ago. de 2018 17:05, Lisandro Damián Nicanor Pérez Meyer <<a href="mailto:perezmeyer@gmail.com">perezmeyer@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Those intersted in avoiding qtchooser, please take a look at this proposal for <br>
Qt's devel mailing list. Thanks!!<br>
<br>
---<br>
<br>
Hi! I would like, this time with enough time, to bring to the table something <br>
that caused us distros some irks in Qt 5: binaries naming.<br>
<br>
The problem is, I think, easy to explain: some binaries had the very same name <br>
for Qt 4 and 5: moc, uic, rcc, qdbus to name some of them.<br>
<br>
Before qtchooser came in a user could not have the same tool installed at the <br>
same time for both versions, or would have to put them in another place other <br>
than /usr/bin or rename them or...<br>
<br>
Admittedly we distro maintainers came up with the issue too late in the <br>
development process (or at least as far as I know), so Thiago created <br>
qtchooser which kind of solved the major issues, but not without drawbacks.<br>
<br>
>From the [list] of bugs it has in Debian in particular, the most interesting <br>
one is that we can not depend upon the binaries it [masks]... simply starting <br>
by the fact that two packages can provide that dependency.<br>
<br>
[list] <<a href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser" rel="noreferrer noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser</a>><br>
[masks] <<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264" rel="noreferrer noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264</a>><br>
<br>
Let's suppose for a minute that Qt 5 and 6 both provide qdbus (could have been <br>
any other app) and that there is a Qt 6 app calling it. Currently the app is <br>
not required to pass -qt6 as a parameter as qtchooser is not mandatory. <br>
Following current practices we have both Qt 5 and 6's qdbus installed. There <br>
are some possible scenarios:<br>
<br>
- Qt 5 is the default version to use.<br>
<br>
  * qdbus has not changed in Qt 6, so Qt 5's version handles the call <br>
correctly.<br>
  * qdbus has changed in Qt 6, so Qt 5's version fails.<br>
<br>
- Qt 6 is the default version to use: nothing happens.<br>
<br>
Now make the app a Qt 5 one and invert the scenarios. And let's hope we get <br>
rid of Qt 4 in the meantime.<br>
<br>
The best solution that we could think of would be to add the major version to <br>
Qt 6's provided binaries, at very least for the ones that keep their name from <br>
Qt 5: uic-6, rcc-6, etc. (another scheme might be preferred, like maybe uic6).<br>
<br>
Note: we are open to other solutions, we have time to discuss this and try to <br>
get a good solution in time.<br>
<br>
Maybe we can relax this for build-time tools if qmake is dropped and the next <br>
buildsystem can use the right tool without the need of special switches, as <br>
currently happens with CMake.<br>
<br>
I also understand that this might not affect other platforms like Windows, but <br>
a move here ideally would need to be done for all platforms for consistency.<br>
<br>
I would like to acknowledge that some people might find qtchooser useful, so <br>
I'm not really proposing to remove it but to have another solution around. <br>
Those who install qtchooser would do it because they know what they are doing, <br>
maybe even testing different Qt compilations in the same machine.<br>
<br>
Cheers, Lisandro.<br>
<br>
-- <br>
Lisandro Damián Nicanor Pérez Meyer<br>
<a href="http://perezmeyer.com.ar/" rel="noreferrer noreferrer" target="_blank">http://perezmeyer.com.ar/</a><br>
<a href="http://perezmeyer.blogspot.com/" rel="noreferrer noreferrer" target="_blank">http://perezmeyer.blogspot.com/</a></blockquote></div></div></div>