[Development] Pending decisions on co-installation

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121031/d5537fe4/attachment.sig>