[Development] Co-installation & library naming rules

[Thiago Macieira]

On sexta-feira, 21 de setembro de 2012 17.33.01, Stephen Kelly wrote:
> 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?

Because we're about to release 5.0 and these problems need to be solved.

I forgot to link: here's where the discussion originated:
	https://bugreports.qt-project.org/browse/QTBUG-27137

> 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)

This is the right way of doing it, provided that the VERSION is mandatory. 
Which is why I am recommending that it be hardcoded in the name instead.

> 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.

This is not a permanent solution nor does it work now. There are three 
problems it doesn't solve:

*Currently*, the packages and dependencies are listed like I listed. We cannot 
require that everyone replace everything now. Won't work.

Further, it won't work for "QtGui < 6.0" since that would select either 4 or 
5. People would have to write "QtGui >= 4.6 QtGui < 6.0", but as I said, 
reality is different.

And it doesn't solve the co-installation problem. We need both 4 and 5 to 
install at the same time.

> > 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.

Who didn't think this far ahead. This is the right way to do it, but two of 
the problems remain.

> > 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?

Sorry, what? I didn't understand.

> > 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.

They can. But we can't require all distros to patch all their .spec files to 
say < 5.0 and >= 5.0 in other places. We could try and this could be done for 
most distros, but it wouldn't solve the problem of source packages by third 
parties.

> > == 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?

First light putting it to words like this.

However, note that glib & family libs *already* follow this convention and 
have done so for years, since their 2.0 release. I just don't think it has 
been codified like I've done.

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

I don't think it's their problem to solve. I think that this is a correct 
change to do.

They won't see it as their problem because the GTK camp has already solved 
this problem for years. From their point of view, they'll see us as the ones 
breaking the rules they already have in place.

And if we refuse to act, they might opt for a path of least resistance and 
rename our files, which in the end hurts us more than it hurts them. See the 
qmake vs qmake-qt4 issue, just like the LSB 4 solution that can't co-install 
Qt 3 and Qt 4.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- 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/20120921/406c6472/attachment.sig>