On Wednesday 14 January 2015 07:24:52 Keränen Pasi wrote: > Hi Kevin and Lisandro, > > I have zero experience with distribution packaging and the problems > therein so sorry if I’m a bit lost here. Thank you Kevin for the links you > sent, I found them informative.
No problem, it happens quite often :) > I followed the Packaging:JavaScript link and it states "Please note that > this section really only applies to JavaScript libraries intended for use > on the web”. Canvas3D and three.js port on top of it are NOT meant to be > used on the web, they are both meant to be used within QtQuick/QML > environment, so running locally as part of your native code (or pure > QtQuick) application. That might be a question for Kevin, but on Debian a javascript library is treated as any other C/C++ library: source code should be there, the binary/minified version must be created from the unminified code at package build time (ie, when building the source code that ships it). It doesn't matter what uses it. > I also read through the Packaging:No_Bundled_Libraries link. I can see the > points made in there, but there is also a good reason why we want to > bundle the three.js together with certain version of Qt and Canvas3D. We > want to deliver a library that we know has been tested together with the > V4 VM and the Canvas3D and we know it should run smoothly there. And by > doing this we add value to our customers. The same can be said about C/C++ 3rdparty libraries. So no, bundling is not good for distros. Imagine a security bug appears: we need to start hunting down each embedded version and fix it, checking that we don't break anything specially in forked cases. A nightmare. > Regarding one of the points made in that document on forks. Yes, at the > moment this port from HTML to QtQuick is a fork of the official three.js > library and lives right next to it in Github. But as I said I’m hoping we > can reduce the delta we have by doing some additional work on the V4VM and > on the Canvas3D. And perhaps if the remaining HTML vs. QML delta is in > only few places and is minimal, we can then persuade the maintainers of > three.js to re-design those few parts to make upstreaming possible with a > clean design. But it's still a fork, meaning semi-duplicated code that we maintainers need to address. Please allow me to be clear in one thing: I *do* understand that for Qt, as long as the license is respected, there is not much of a problem. What I've expressed here is what us distro maintainers face with this actions. -- 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
