On Friday 27 June 2014 11:28:14 Koehne Kai wrote: [snip] > My 2 cents from the packaging/installer side: Any artifact that is heavily > bound to a specific Qt build / release, but isn't part of the Qt package > itself, is making things complicated.
As distro packager, yes, it's making things complicated. [snip] > That's of course only the binary installer ... I can't judge whether e.g. > distributions would appreciate separate releases of QtWebEngine. No if it uses private headers. I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5 each time I upload a new point release for this exact problem [0]. I would really like to avoid adding new stuff to that list, as it is a real PITA. [0] Even if API/ABI matches, there seems to be a runtime detection of different versions of Qt in qobjectprivate. I can really understand why that check is there, so the best solution is to avoid "third party" stuff to use private headers. Having a different release schedule will certainly make any package count as "third party" in my POV. -- Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
