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

Kevin Kofler kevin.kofler at chello.at
Tue Jan 20 05:04:05 CET 2015


Thiago Macieira wrote:
> That logic is inverted. It needs to try qmake first because it might be a
> more recent version, installed by a binary from the Qt Project, since we
> don't rename. Any qmake-qt4 tool, if present, is an older version from the
> distribution.

The only thing I promised is that if there is a Qt 4 qmake in the PATH, it 
WILL find it. Now if there is more than one version, which one is the 
preferred version is arguable. I'd argue that the distribution's Qt is 
always the preferred one unless the user explicitly requests something 
different. (And by the way, we wouldn't have this problem if you were 
finally shipping suffixed binaries upstream.)

As for "an older version from the distribution", some "koji latest-pkg" 
output for you:

Build                                     Tag                   Built by
----------------------------------------  --------------------  ------------
qt-4.8.6-20.fc22                          f22                   rdieter
qt-4.8.6-18.fc21                          f21-updates           rdieter
qt-4.8.6-18.fc20                          f20-updates           rdieter

"Older", you say? It's actually NEWER than your latest upstream release 
because it includes some backported patches.

Now, before you claim this is easy for the legacy Qt 4, here's the data for 
Qt 5:

Build                                     Tag                   Built by
----------------------------------------  --------------------  ------------
qt5-qtbase-5.4.0-6.fc22                   f22                   rdieter
qt5-qtbase-5.4.0-2.fc21                   f21-updates           rdieter
qt5-qtbase-5.4.0-2.fc20                   f20-updates           rdieter

> Renaming the tools creates other problems. We needed a compromise and
> qtchooser is it.

I still have not heard of a single problem that renaming the tools upstream 
(and thus for all downstreams) would cause. (Of course, you would actually 
ship BOTH the old and new name for the lifetime of Qt 5, otherwise the 
compatibility problems are obvious. This would not have been an issue if the 
rename had been done back in 5.0.0. Qt 6.0.0 will be the next opportunity to 
get rid of the legacy names.)

> That won't happen because those applications will get written for the
> official binaries from the Qt Project, which do not contain renamed tools.
> Do you really think people will write software that doesn't compile with
> the official version?

Software on GNU/Linux often gets developed against distribution -devel 
packages. I definitely do that whenever possible. Do you really think that 
all developers of Qt-using software download your upstream binaries or build 
your source code themselves, when they can just "yum install qt-devel"? That 
said, what Qt setup is encountered of course depends on the distribution the 
developer(s) is/are using.

> Remember: you (implicitly) agreed with the solution in 2012.

I did not agree with anything at all.

You brought up a discussion on a Qt Project mailing list, to which most 
distribution packagers are not even subscribed. You got only very limited 
feedback from distributors. You never bothered to approach distributors 
through places they follow, such as the kde-packager (at the time) mailing 
list (or even OUR mailing lists, or aliases such as
qt-owner at distro.example.com), at least not before the decision was made. It 
is only coincidence that I learned of the discussion at all, when it was 
already at a late stage. Assuming that all the people you did not ask agree 
with you just does not make any sense whatsoever.

> If you unilaterally choose to deviate from it,

Our intentions have been clearly announced on our mailing list, IRC channel 
and publicly-logged IRC meetings from day 1. By not objecting, by your own 
logic, you implicitly agreed to them.

        Kevin Kofler




More information about the Development mailing list