Qt 6 and binaries naming

[Lisandro Damián Nicanor Pérez Meyer]

Ping?

El sáb., 4 de ago. de 2018 17:05, Lisandro Damián Nicanor Pérez Meyer <
perezmeyer at gmail.com> escribió:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20180918/03459c8f/attachment.html>