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

Kevin Kofler kevin.kofler at chello.at
Mon Jan 19 15:30:48 CET 2015


Thiago Macieira wrote:

> On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
>> Therefore, we are NOT shipping qtchooser in Fedora by default, and our
>> qtchooser package in the online repository (package which we only ship at
>> all due to the insistence of one individual packager – both I and the
>> primary maintainer of Qt in Fedora have requested its removal from Fedora
>> more than once) does NOT automatically add itself to the PATH.
> 
> Please reconsider. There's something to gain just by being compliant with
> what we standardised and recommend.

I just realized yet another showstopper that precludes supporting qtchooser 
in Fedora by default: A core assumption in qtchooser's design is that the 
unsuffixed binaries in the default PATH ("default binaries") all default to 
the same version of Qt. But this is not how things work in Fedora: In an 
effort of being as compatible with upstream as possible, we have only added 
suffixes where there are actually conflicts. As a result, the "default 
binary" is the one where the given binary was first introduced (except that 
we do not support Qt 1 or 2 anymore, so Qt 3 is the minimum we care about). 
For example, the default "qmake" is the Qt 3 one, the default "qdbus" is the 
Qt 4 one, the default "qtpaths" is the Qt 5 one. The qtchooser wrapper does 
not support this setup, and thus enabling it by default would be a 
backwards-incompatible change and might break several Qt 3 or 4 packages.

This would have been an issue even if we had picked up qtchooser immediately 
when it was introduced, because we already had this mixed setup for Qt 3 and 
4 binaries. (Excluding the Qt >= 4 binaries from qtchooser wrapping entirely 
would not have worked because of Qt 5.)

        Kevin Kofler




More information about the Development mailing list