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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
