On Tue, Jan 20, 2015 at 01:55:41PM +0100, Kevin Kofler wrote: > Some programs need adaptations to build on distros because they do not > expect the binary names we ship. > but that work has already been done, long ago. even adjusting it to qt6 at some point will be a rather trivial effort (and zero for you if you bothered to upstream build system improvements that make upstream packages work out of the box with packaged qt).
> > you can't do it, because distros won't agree among themselves. so > > upstream mandating a solution by renaming the binaries itself is > > necessary. hilarious. as if that would keep anyone from doing what > > they want anyway. > > If upstream were to ship suffixed binaries such as qmake-qt5, it would do 2 > things: > 1. ensure that some distro won't come up with its own naming scheme, e.g. > qmake5, q5make, qt5-qmake, qmake_from_Qt_5 or whatever some packager can > dream up (if the official binaries are called "qmake-qt5" etc., there > will be no reason for a distro to use any of the other names), > but this is already the case, and has been since qt2. so that ship has sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the debian (?) guys made clear that they'll keep their qmake5 (?) scheme anyway - they must, for compat reasons. so whatever we do is add-on only anyway. and if a *new* distro chooses *yet* another scheme ... well, shoot them. i suggested that the qt project should publish packaging guidelines, so there would be no need to become homocidal. also consider that this problem is "a tad" bigger than just qt. you really need to define a cross-distro standard anyway. > 2. ensure that programs/scripts do not have to handle both renamed and > unrenamed binaries, because ALL Qt binaries (from ALL distros and from > upstream) should then be using the renamed ones (as there would be no > reason to rename it back to "qmake", at most to ship both variants for > compatibility). > but as others pointed out, the name clash of qmake from qt4 and qt5 is advantageous in some porting scenarios. and in case of unified dispatchers like qtchooser (and lots of custom scripts), divergence would be actively counter-productive. given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
