[Development] Co-installation & library naming rules

[Thiago Macieira]

On quarta-feira, 10 de outubro de 2012 18.03.31, Oswald Buddenhagen wrote:
> On Sun, Sep 23, 2012 at 08:30:31PM +0200, Erik van Pienbroek wrote:
> > why not solve the problem at the level where it's supposed to be
> > fixed, upstream?
> 
> i disagree with your premise. ;)
> the whole proposal addresses only one specific issue: conflicts between
> major qt versions. like it or not, this is an issue specific to linux
> distributors. which translates to some 20 people in the world who even
> need to think about properly solving it.

Indeed. But their output affects a lot of people, including the majority of 
future Qt contributors, which have traditionally come from the Linux 
background. We need to provide a correct experience for those.

> what about different build configurations of the same version (i.e.,
> your x-compiling use case)? qmake5-win32-pc-i386?

Good point. Following GCC's lead, we could provide an option to have the 
executables include the arch name. But that should not be the default in non-
cross-compilation builds.

> what about concurrent minor version of the same major version? qmake5.1?

Not necessary. qmake retains the necessary backwards compatibility. The newer 
version replaces the previous with all functionality necessary.

Co-installing multiple versions of the same major-version package requires 
renaming beyond what we (or GCC) support. That's really up to distributors.

> by encoding the major version but nothing else in the basenames of the
> artifacts, those who have more complex setups are forced to use double
> namespacing.
> 
> nope, sorry, the version-based namespacing simply does not belong into
> upstream. it's a problem specific to FHS, and should be addressed by
> those concerned with it.

It belongs in Qt and people have already agreed to it. We need to fix it in Qt.

-- 
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/20121010/699db39d/attachment.sig>