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? _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
