[Development] New proposal for the tool naming

[Oswald Buddenhagen]

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?