[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