Hi Rinigus, On Sat, Jun 01, 2019 at 09:33:41AM +0300, rinigus wrote: > In my understanding, special branch was made to incorporate it into Qt, see > https://github.com/qt/qtlocation/blob/5.12/.gitmodules > > The corresponding branch should comply with all common Qt requirements, > including the license. Note that Qt requirements are not the same as our DFSG requirements. In my previous mail I mentioned the JSON license which is not allowed in Debian. It looks like things got a bit better since then — it is still mentioned in LICENSE.md [1] but I cannot find the actual code. > In this respect, it looks like arguments against packaging Mapbox GL module > of QtLocation are not linked anymore to the license nor inclusion of > third-party code. Instead, it is mainly related to the size of it, right? Maybe there are no more license problems, but the problems with inclusion of third-party code persist. Most of the deps/ directory [2] is third-party code, and the Qt build is using all of them [3]. The best practice in Debian is to package each of dependencies separately. It is obviously not achievable in this case. However, the situation when Qt bundles Mapbox and Mapbox bundles 17 other pieces of software is far from ideal. This is a dependency hell and hard to maintain. That is why I would prefer if at least Mapbox (together with its bundled stuff, maybe) was packaged separately from Qt Location. This way it would be much easier to adopt to its build system, track upstream bugs, backport patches, etc. I tried to find the difference between upstream version and Qt version. The latter claims to be based on upstream commit 377a6e42d687c419 [1]. However, the diff between that commit and qt-staging branch is: 6195 files changed, 730722 insertions(+), 645574 deletions(-) This is a huge diff and it would be a pain to maintain this branch. For some reason Qt does not use merges or rebases on master branch, so it is even harder to track what they changed. If a bug is fixed on upstream branch, how will be cherry-pick the fix? > When using Qt, I would expect that all its parts (or open-source parts) are > available on the platforms that package it. So, when I want to run a code > that is calling Mapbox GL plugin, it should be possible if QtLocation >= > 5.9 is packaged. Took some time to dig out why its not there on > Debian-based distros and it seems now that the reason which holds is just a > size, not license. I don't think it is a valid point to drop a part of it > just due to the size. In this respect, it looks like a bug in packaging. This is a valid expectation. In an ideal world we would provide this plugin in our packaging. However, as I explained above it would be difficult to maintain it as is, and both Lisandro and I have very little time to do it properly. Some time ago people convinced us to package Qt WebEngine that bundles Chromium, and I now have to spend a lot of time trying to figure out build failures, copyright issues, etc. with each new release of it. I do not have time for another monster like that. > As for finding dedicated maintainer - I don't think its necessary, as it is > not necessary to find dedicated maintainer to > https://github.com/qt/qtlocation/tree/5.12/src/plugins/geoservices/esri > plugin, for example. QtLocation is released after corresponding tests and > should have testing done as a whole as well. It looks to me that splitting > a package that was developed as a unit and then finding a way to glue it > back together (splitting qmapboxgl out of qtlocation and gluing it then > back) is making extra work for not much gain. But I am not in packaging > business - in writing software business instead - and can provide my 2c > only from outside. If Qt uses a submodule pointing to upstream repo, this means this package was *not* developed as a unit. > Note that situation with Pure Maps is somewhat different and I may converge > to using QtLocation plugin system later as well to avoid keeping my QML > bindings up-to-date. But I think covering full functionality of QtLocation > is an expectation of the users from distribution. Can you please file a bug against qtlocation-opensource-src source, explaining your situation? This way if things change in future (e.g. the code becomes cleaner, we suddenly have more time, we find another volunteer to do the work, …) it would be easier to remember about it. [1]: https://github.com/mapbox/mapbox-gl-native/blob/qt-staging/LICENSE.md#open-source-software-licensed-under-the-json-license [2]: https://github.com/mapbox/mapbox-gl-native/tree/qt-staging/deps [3]: https://github.com/mapbox/mapbox-gl-native/blob/qt-staging/mapbox-gl-native.pro#L408 [4]: https://github.com/mapbox/mapbox-gl-native/commit/0130c58fdd74edbb -- Dmitry Shachnev
Attachment:
signature.asc
Description: PGP signature