Qt 6 and binaries naming

[Lisandro Damián Nicanor Pérez Meyer]

Those intersted in avoiding qtchooser, please take a look at this proposal for 
Qt's devel mailing list. Thanks!!

---

Hi! I would like, this time with enough time, to bring to the table something 
that caused us distros some irks in Qt 5: binaries naming.

The problem is, I think, easy to explain: some binaries had the very same name 
for Qt 4 and 5: moc, uic, rcc, qdbus to name some of them.

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 rename them or...

Admittedly we distro maintainers came up with the issue too late in the 
development process (or at least as far as I know), so Thiago created 
qtchooser which kind of solved the major issues, but not without drawbacks.

From the [list] of bugs it has in Debian in particular, the most interesting 
one is that we can not depend upon the binaries it [masks]... simply starting 
by the fact that two packages can provide that dependency.

[list] <https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser>
[masks] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264>

Let's suppose for a minute that Qt 5 and 6 both provide qdbus (could have been 
any other app) and that there is a Qt 6 app calling it. Currently the app is 
not required to pass -qt6 as a parameter as qtchooser is not mandatory. 
Following current practices we have both Qt 5 and 6's qdbus installed. There 
are some possible scenarios:

- Qt 5 is the default version to use.

  * qdbus has not changed in Qt 6, so Qt 5's version handles the call 
correctly.
  * qdbus has changed in Qt 6, so Qt 5's version fails.

- Qt 6 is the default version to use: nothing happens.

Now make the app a Qt 5 one and invert the scenarios. And let's hope we get 
rid of Qt 4 in the meantime.

The best solution that we could think of would be to add the major version to 
Qt 6's provided binaries, at very least for the ones that keep their name from 
Qt 5: uic-6, rcc-6, etc. (another scheme might be preferred, like maybe uic6).

Note: we are open to other solutions, we have time to discuss this and try to 
get a good solution in time.

Maybe we can relax this for build-time tools if qmake is dropped and the next 
buildsystem can use the right tool without the need of special switches, as 
currently happens with CMake.

I also understand that this might not affect other platforms like Windows, but 
a move here ideally would need to be done for all platforms for consistency.

I would like to acknowledge that some people might find qtchooser useful, so 
I'm not really proposing to remove it but to have another solution around. 
Those who install qtchooser would do it because they know what they are doing, 
maybe even testing different Qt compilations in the same machine.

Cheers, Lisandro.

-- 
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://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20180804/0940d723/attachment.sig>