On quinta-feira, 1 de novembro de 2012 11.56.25, Lincoln Ramsay wrote: > On 01/11/12 09:41, Thiago Macieira wrote: > > On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote: > >> On 01/11/12 01:02, Thiago Macieira wrote: > >>> Also, do I understand correctly that you're suggesting that multiarch > >>> > >>> distributions should have *both*: > >>> /usr/lib/qt5//bin/assistant AND > >>> /usr/lib64/qt5/bin/assistant > >>> /usr/lib/qt5//bin/linguist AND > >>> /usr/lib64/qt5/bin/linguist > >>> /usr/lib/qt5//bin/designer AND > >>> /usr/lib64/qt5/bin/designer > >> > >> hang on... why shouldn't they have both of those? > >> > >> a 32-bit assistant is different to a 64-bit assistant > > > > How are they different? > > Well for one thing, you can't run the 32-bit one against a 64-bit > install or vice versa. Any plugins they load (including system style > plugins) must be the same bit-ness. Designer used to load plugins for > custom widgets... not sure if it still does.
Sure, you can't run against the wrong install. But the presence of the executable assumes that its dependencies are present and properly installed. So that's not an argument. This is how Linguist, Assistant, xmlpatterns, xmlpatternsvalidator, qglinfo, qdbus, and qdbusviewer go. Their purpose is completely independent of the arch. The plugin argument for Designer has been discussed. So far, our conclusion is to punt the problem because QtWidgets is in Done state. We've punted the problem to the plugins themselves: we're requiring that the plugins be updated to Qt 5, along with Designer itself. Designer's output (the .ui file) is arch-independent and even backwards compatible. As QtWidgets and Designer are in Done, we're not expecting any new features. But even if some come along, the precedent set by tools like Microsoft Word and Libre Office is that you simply provide an option in the Save dialog to save as the previous version. Heck, I thought Designer in Qt 4 still had the option to save as a Qt 3 .ui file, for uic3. I can't find it, though. Also note that, unlike uic3, uic does not load plugins, so all the information it needs to generate the .h file is already present in the .ui. Therefore, if the plugins are updated to Qt 5 and they themselves retain their compatibility of purpose, a file saved by Designer/Qt5 will be processed correctly by uic/Qt4. > If you're on a 64-bit distro, you most likely don't want the 32-bit > versions. If you're on a 32-bit distro, you can't use the 64-bit ones. > That's a distro/packaging problem though. The best we could do is to > remove these from the Qt repo and build/packge them separately (like we > do with Creator). Right, that's a packaging problem. But it's a problem that has been solved by distributions when they first came up with multiarch. For example, for Fedora, a file may belong to both arches, but the 64-bit one wins: $ rpm -qf /usr/bin/mysql_config mysql-5.5.28-1.fc17.x86_64 mysql-5.5.28-1.fc17.i686 $ file /usr/bin/mysql_config /usr/bin/mysql_config: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x815aa7c206d463b192ed09b42965796b4f2e4d05, stripped If designer exists in one common path, outside of LIBDIR, the existing multiarch mechanisms kick in and fix the problem of duplication. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
