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

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 19 January 2015 20:25:55 Thiago Macieira wrote:
> On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
> > [snip]
> > 
> > > > So, as Sune Vuorela also explained, having multiple major versions of
> > > > Qt
> > > > in
> > > > parallel is always going to be a fact of life.
> > > 
> > > Indeed, but the Qt devs' original proposal was to simply put it outside
> > > /usr/bin, possibly even outside of $PATH. If distros had accepted to
> > > install Qt in (say) /opt/qt5, there would have been no qtchooser, no
> > > renaming and no need for change anywhere in our buildsystem. But distros
> > > refused to do what we asked...
> > 
> > For the sake of completeness, we are not allowed to do so in the same
> > strength that the Qt project doesn't allows binary incompatibility between
> > minor versions, and for which us downstreamers are very grateful :)
> 
> I know you're not allowed to do that, but there's no technical reason why
> that is so. Unlike binary compatibility. It's a choice.

You might want to take the Filesystem Hierarchy Standard as a technical 
reason, plus the fact that we do our best to keep stuff installed by packages 
away from stuff installed by the system's admin, like /opt, simply to avoid 
problems.
 
> But contrast that to the distros asking for the renaming and the majority of
> Qt developers rejecting that. The ideal solution for either group was
> rejected outright as soon as the discussion began. So we had to come up
> with alternatives and compromises.

Yes, I know. And I think it was with that good faith of trying to work out an 
alternative that Sune and I (and mostly thanks to Sune, because at first I was 
really confused with the situation) decided to go the qtchooser way.

Is it in that same light of alternatives and compromises that I'm at least 
asking to reconsider the case of user-facing stuff, and to take into 
consideration all the experience we gained during this for the next major 
release. We distros might not get the best solution, but at least let's work 
to try to let users don't get into bugs we know might happen.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150120/fd66fd3c/attachment.sig>