[Development] New proposal for the tool naming

[Oswald Buddenhagen]

On Tue, Oct 23, 2012 at 08:25:19AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote:
> > > Because qdbus should be in /usr/bin but the version- and arch-specific
> > > qmake should be somewhere in /usr/lib*/qt5.
> > 
> > ok, i can buy that as such.
> > however, i totally see no point in us doing this upstream, and why qmake
> > (or even qlibraryinfo) should be in any way concerned with it.
> 
> 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.

> > > So we provide symlinks for a few of the tools in addition to qmake, but I
> > > don't see why moc should be in $PATH. The number of people who actually
> > > run it manually must be countable in one hand.
> > 
> > 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. the problem you are trying to solve is
limited to co-installation into a single path, which is a policy-imposed
problem of linux distributions. it is incredibly silly to claim that
something that does not comply with this policy is broken by definition.

> > > On the other hand (the one not counting people), applications like qdbus
> > > or
> > > xmlpatterns make no sense to have in duplication.
> > 
> > actually, xmlpatterns (just like lupdate) can be usefully called both
> > manually and from build scripts.
> 
> 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.

> > > I would prefer to have the tool inside qtbase, [...]
> > > 
> > > since this tool is the entry point for building Qt5-based applications, it
> > > must either come with Qt or not depend upon it.
> > 
> > actually, not at all.
> > as we established, this is an entirely optional, external add-on. it's
> > not necessary for building qt at all - the environment in which qt is
> > built can be very well self-contained, as it has always been.
> 
> If we add the "-qt5" option to the traditional qmake, then it can be 
> considered optional.
> 
huh?