Hi Dmitry, 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. >
Which is good, I presume. > 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]. > Sorry, I missed those. > 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? > As far as I understood from following these Qt releases - they have Qt team which manually syncs the source of the master branch to the one in Qt. I don't know why they selected to do so, I presume there was some important reason why the didn't synced the branches on commit level. As a result, you have issues with comparison. > > 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. > Well, compared to WebEngine probably anything is teeny-tiny. But I understand the reservations regarding it. [...] 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. > > Yes, will do. Thank you very much for detailed replies and constructive discussion! Rinigus
