Oswald Buddenhagen wrote:
> correct. as far as i'm concerned, the purpose of qtchooser is to be a
> frontend tool which targets developers working with multiple qt
> versions, regardless whether these versions come from distro packages or
> own builds.
The thing is, we asked for something that fulfills distro's needs. You shot
that down and instead got Thiago to implement something different. And now
you say yourself that it is not what was asked for.
Developers working with multiple versions of Qt 5 are by far the minority.
Most users of Qt development packages actually just want to compile software
somebody else wrote. And even those that actually are developers are usually
happy with our regularly-updated builds of the latest stable Qt release. To
all those users, different major versions are the ONLY coinstallation case
that matters.
> build systems which target specific (major) qt versions are simply out of
> scope.
Says who? That is by far the common case. Very few programs support more
than one major version of Qt.
> your problem is a self-made one: the attempt to co-install major
> versions of everything.
As long as there are new major versions of Qt (i.e., new versions that are
not 100% drop-in replacements for the previous version), there WILL be a
need for coinstallation. Programs do not magically port themselves
instantly. Even the upstream developers themselves need time to port things.
Distribution packagers are usually not qualified to do such a port, so we
need to wait for upstream to do it (and even if we were to attempt porting
the software ourselves, it would probably take even longer). And then, as I
wrote in the first paragraph, there is also software compiled by end users
on their own. And finally, there is some software that never gets ported. It
is stuck on an obsolete Qt version, but it works and is useful to our users,
so dropping it would be a disservice to our users.
So, as Sune Vuorela also explained, having multiple major versions of Qt in
parallel is always going to be a fact of life.
> this is a linux distro specific problem,
Only because we are the only operating system to actually support building
software without messing with path settings all over the place.
I'll also add that even for those operating systems (such as Windows) where
you do have to tweak PATH, having non-conflicting executable names allows
setting the PATH once in the user-wide or system-wide settings in the
control panel and not having to run a setpaths.bat once for every single
build.
> and demanding x-platform upstreams to accept trade-offs to adjust to it is
> *unreasonable*.
What trade-offs do they have to accept? They just need to add "-qt5" to the
name of the binary / .EXE file / whatever that they run in their build
scripts, once. (And only if they do not simply use a third-party build tool
that does the right thing for them already.) In exchange, the program will
always compile fine even if there is also a Qt 4 in the systemwide PATH, a
situation that can occur on ALL operating systems (including ones not
supported by qtchooser), as I explained.
> now, you will say that most users under linux use qt via distro
> packages. that's right. and you know what? it's *your* task to make it
> work for them.
And we are. But Thiago is complaining about it.
> if upstreams of qt-using applications choose to support distro-packaged
> qt (via having preference lists of suffixed qmakes, for example), that's
> a perfectly reasonable thing to do. if distros among themselves want to
> standardize on a pattern to ease this, i'm all for it. it's still not
> something *we* (qt upstream) need to be concerned with.
Now this is really funny. We wanted to do the renaming upstream. You were
one of those people who shot it down. Now you are saying we should just do
it downstream. On the other hand, Thiago also wanted to do the renaming
upstream, he was told not to, so he implemented qtchooser instead, and now
says that everybody should use qtchooser and that anything else is broken.
Since it is clear even to you that qtchooser is not what we want, why did
you force Thiago to implement it, and why are you still not willing to allow
the proper solution to be implemented upstream?
I'll also point out that, while Debian currently does use qtchooser by
default, Lisandro from Debian also stated that he would prefer suffixed
binaries. I am not sure there is even ONE distro that is happy with
qtchooser.
> i consider this discussion closed, including for qt6.
And I think that this is a mistake. There is a real problem here, one that
affects ALL your downstreams (not just GNU/Linux distributions). In Qt 4,
upstream's answer was to ignore the issue. In Qt 5, qtchooser was
introduced, which solves a different problem from the one we are having
(namely, letting the USER choose between different Qt versions that ARE
drop-in replacements, i.e., different variants of the same major version).
Coaxing it into solving our problem introduces more issues than it solves.
Why can we not finally get the right thing to happen for Qt 6, or even (with
the soft migration path I described elsewhere in this thread) upcoming Qt
5.n releases? The right thing can be done, see e.g. KF5.
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
