On Tue, Oct 23, 2012 at 10:18:38AM -0700, Thiago Macieira wrote: > On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote: > > > We've been over this: because I'd rather do this right and once and for > > > all. Who are the best people to make sure that all tools continue to work > > > under those conditions? Upstream is. > > > > the thing is that this is a non-change. *nothing* needs to be changed in > > the sources - it's only a question of where the package manager is told > > to put the executable. i don't see why we should introduce any > > complexity upstream for a problem that is cleanly solved by downstream > > for decades. > > You do realise that there has been *no* clean solution developed downstream, > right? Much less for decades. > > Renaming qmake to qmake-qt4 is not a clean solution. [...] > this paragraph was about splitting out "apps" from qt's common bin dir (which would be isolated anyway). therefore the rest of your response is misapplied.
> > > > i'm pretty sure that *some* build systems rely on moc being in the path. > > > > one could argue that they are broken - but then, it exactly fits the > > > > /usr/bin philosophy, so it's hard to blame them. > > > > > > We've been over this, again. If they rely on $PATH without user > > > intervention, they are already broken, as /usr/bin/moc might be Qt 4's. > > > > they are not broken, because relying on a correctly set up $PATH is an > > entirely reasonable position. > > I beg to differ, again. That's the position we've been taking for the 15 > years > of the existence of moc and the 10 years of qmake, but we've not been > listened > to. > > We may think and we definitely have thought it was reasonable to ask. But > history shows that we haven't been listened to. Therefore, it's not > reasonable > to *keep* asking. > this paragraph was about released 3rd party apps, and therefore entirely out of our control. we can only make it worse for them. > > > True, but unlike lupdate, the functionality, purpose and output do not > > > change from version to version. The Qt 5 xmlpatterns cleanly replaces the > > > old Qt 4 one. There's no need to duplicate. > > > > your idea doesn't work anyway. the distros won't have the users install > > the qt5 libraries just because the user requested an xmlpatterns > > package, when a qt4-based xmlpatterns can be had almost for free for > > those which already have qt4 libs installed. and some distros won't have > > two alternative xmlpatterns packages which provide the same binary - > > because of non-conflict policies. the bottom line is that there will be > > qt version bound sets of all tools and apps, and that they will have to > > meet the co-installability requirements. > > The difference is that xmlpatterns, like qdbus and the other > applications, can be updated by the Debian alternatives mechanism. > yes, debian. have you checked that this is true for all relevant downstreams? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development