[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

Kevin Kofler kevin.kofler at chello.at
Tue Jan 20 13:55:41 CET 2015


Oswald Buddenhagen wrote:
> but i do. my purpose was to keep the imo (slightly) detrimental change
> out of qt, and enabling our developer use case to be convenient. i never
> considered the distro case relevant as such - i demonstrated why it is a
> non-issue back then, and i did it again in my previous mail. there is
> simply no problem that needs solving upstream. the fact that fedora
> successfully ships qt5 packages proves this.

The problems are those that Thiago already mentioned: Some programs need 
adaptations to build on distros because they do not expect the binary names 
we ship. (That said, this is indeed the lesser evil compared to the problems 
qtchooser causes.)

> correct. there is no problem at all if you put the binaries of each qt
> build into an own directory (a subdirectory of qt's libexec would be
> probably right, even if it sounds backwards at first) and then alias
> them from /usr/bin with suffixes.

This is, in fact, exactly what we are doing.

> no, i already said it back then. and your (or maybe rex') argument was

I think Rex wrote that.

> - literally - that you can't do it, because distros won't agree among
> themselves. so upstream mandating a solution by renaming the binaries
> itself is necessary. hilarious. as if that would keep anyone from doing
> what they want anyway.

If upstream were to ship suffixed binaries such as qmake-qt5, it would do 2 
things:
1. ensure that some distro won't come up with its own naming scheme, e.g.
   qmake5, q5make, qt5-qmake, qmake_from_Qt_5 or whatever some packager can
   dream up (if the official binaries are called "qmake-qt5" etc., there
   will be no reason for a distro to use any of the other names),
2. ensure that programs/scripts do not have to handle both renamed and
   unrenamed binaries, because ALL Qt binaries (from ALL distros and from
   upstream) should then be using the renamed ones (as there would be no
   reason to rename it back to "qmake", at most to ship both variants for
   compatibility).

        Kevin Kofler




More information about the Development mailing list