[Development] Co-installation & library naming rules

[Stephen Kelly]

On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote:
> Rationale:
> ----------
> 
> This is a rewriting of the book in how to name a library.

It seems like it might be something to bring up in a wider scope (with distros 
for example). This isn't Qt specific. Has it been an issue before? Why solve 
it now?

> == Enter other tools ==

> As was shown by CMake months ago, we cannot have the
> Qt 5 packages called "Qt" as those conflict with the ones in Qt 4. 

For clarity, I guess you mean that we chose not to use 

 find_package(Qt VERSION 5)

We could have, but for several reasons (for example, symmetry with 
find_package(Qt4), easier to implement without having to think about 
conflicts, etc).

but instead we chose to have multiple separate modules like this:

 find_package(Qt5Core)

We could also have used 

 find_package(QtCore)

but I couldn't build concensus to remove the major version number from there. 
Of course, to disabmiguate, users could have used 

 find_package(QtCore VERSION 5)

or

 find_package(QtCore VERSION 6)

as desired. Having the version number in the name in the case of the CMake 
files is not really required, but I gave up trying to build consensus on that.

> Buildsystems based on pkgconfig will often have a requirement of the form:
> 	QtCore >= 4.6 QtGui >= 4.6
> or even simply:
> 	QtCore QtGui

It is also possible to specify QtGui < 5.0. Any distro where that is needed, 
but not present is a bug in the distro.

> 
> Those requirements do match the Qt 5 libraries:
> $ pkg-config --libs QtCore \>= 4.6 QtGui \>= 4.6
> -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui

$ pkg-config --libs QtCore \>= 4.6 QtCore \< 5.0
Requested 'QtCore < 5.0' but version of Qtcore is 5.0.0

> Whether that is correct or not is unknown to pkg-config. 

But it is known to the user of pkg-config.

> It could be right
> if the application has already been ported to Qt 5. In the case of most
> applications existing today, it is incorrect.
> 
> But it could be right for other libraries. For example, for libpng:
> $ pkg-config --libs libpng \>= 1.2
> -lpng15
 
It seems like it would be nice for pkg-config files to be able to contain a 
maximum version number for some start-number. Is that possible? 

> The fact that our pkg-config files have the same name also impacts the co-
> installability of Qt 4 and Qt 5, and a little more: Linux distributions
> *will* carry Qt 4 for a number of years to come (they still have Qt 3).
> Therefore, they must be able to at least have both sets of packages in
> their
> repositories. The problem comes when their buildsystems make reference to
> pkg- config files, such as in RPM-based distros:
> 
> BuildRequires: pkgconfig(QtCore)

I don't know anything about RPM, but I would be surprised if they can't 
specify versions there. If they can't, then that's a global bug for them, not 
a local one for us.

> 
> Since the distribution contains packages for both versions of QtCore, it is
> now ambiguous which one would be selected for building.

>From what I know about distros, they are capable of handling versions like 
this, so this is a solved problem, no?

> Selecting the 5
> version now would be wrong, just as selecting version 4 in a few years'
> time.

This is a distro problem to solve.

> == Proposal ==
> 
> The library naming rules must be modified.

Is this the first light for this proposal, or have you brought this to distros 
attention already? 

Why do you think it's our problem to solve and not theirs?

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120921/085d48b5/attachment.sig>