On Mon, Jan 19, 2015 at 07:30:46PM -0800, Thiago Macieira wrote: > On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote: > > 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. > > I'm agreeing with Kevin here. [...] > > So no, don't tell us qtchooser is not meant to solve distros' > problems. It's meant exactly for them. > 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.
> > > build systems which target specific (major) qt versions are simply > > > out of scope. > > > > Says who? > says me. and in case you already forgot the context: we're talking about the scope of qtchooser at this point. of course one can insist on making qtchooser (used explicitly, not relying on aliasing) the only blessed interface for build systems, but i think it's obvious that this idea is a non-starter. > To be clear: Ossi was talking about development files and tools, not > about the libraries. And also note he's referring to another self-made > problem of not allowing binaries outside of /usr/bin. > 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. > > > 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. > correct. > > Now you are saying we should just do it downstream. > no, i already said it back then. and your (or maybe rex') argument was - 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. > > > i consider this discussion closed, including for qt6. > > You don't get to decide that. First of all, you can't tell what the > environment for Qt 6 will be. > the assumption is obviously that the "environment" won't change. i don't see how it could, and what i've seen so far doesn't suggest that i'm overly optimistic with that prediction. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
