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].
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