Discuss reconciling the Qt requirements for Ubuntu vs. Kubuntu

[kitterman]
Based on the experience to date there are several issues that need to be sorted. In general, I think that what the Kubuntu team will want is the same things we've wanted when Canonical wanted to push changes into Qt4:

1. Work upstream as much as possible. Even if, due to release schedules or other factors, it's necessary to land a new feature in the Ubuntu packages first, get agreement on the change with upstream so that the divergence is temporary.

2. Don't use private Qt5 headers. In Debian, the Qt-KDE team will only create private-dev packages sufficient to get Qt5 to build. If there are other currnently private headers needed, Ubuntu will end up with a packaging diff to maintain (beyond the other headaches that go with depending on private headers). Work with upstream to get them made public. See qtsensors-opensource-src for a current example.

3. Push patches upstream and to Debian.

4. Switch to QPA. The forward port of the Qt4 appmenu patches was supposed to be only for 13.04, but it's still there.

5. We need to decide what to do about making qreal == double in arm*. Upstream this will come with 5.2 [yes - it's a BIC change without soname bump, upstream isn't perfect either]. There's a compile time option to leave it as float if we want it. The trade off is, I believe, a stack of package rebuilds to do essentially a library transition without soname bump versus we gain fewer porting issues (developers assuming qreal == double everywhere is the #1 porting issue for Qt apps on arm) and matching upstream. Debian has not decided, but it looks like they will likely make qreal == double on armhf and arm64 and leave it as float on armel (and sh4) since the arm hardware they support with the armel port doesn't all have hardware FP.

6. Need to agree on a major upstream version to target for 14.04, presumably 5.2.
[slangasek] one of the concerns from Canonical's side, and the reason this session was proposed, is that it may not be possible to agree on a major upstream version. Both Kubuntu and Ubuntu Touch leverage Qt very heavily, and if they aren't on precisely the same page in terms of upstream support that they need for 14.04, we could have conflicting requirements. Maybe we are all on the same page and this is a non-issue, but this is something we should talk through to be sure we have a plan.
[kitterman] For 14.04, I think it will not be a problem, but we should still have this discussion now, because eventually, it will be. The most important thing now is to work out a shared management process and agree on how we decide. The most important technical issue to resolve, because it's likely to lead to these kinds of disconnects in the future, is the use of private headers in Qt. Those can change without warning and that creates risk.

7. [janimo] The possibility of eventually running Ubuntu Touch on x86 presents another issue, as currently there is an implicit assumption that arm == GLES and x86 == GL. AFAIK the proprietary x86 graphics drivers for the desktop only accelerate GL, whereas Touch requires GLES.

I don't think that there is any reason why the Qt5 packages can't generally be uploaded to Debian (even if it's Experimental) and sync'ed to Ubuntu. I haven't checked all the Qt5 packages, but the ones I have checked I didn't see any fundamental differences in requirements that would preclude it.
[Mirv] The analysis at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1219695 should still be about valid. Most packages would be possible to directly sync from Debian unless eg. time constraints require to upload a similar package first to Ubuntu.

I know work is going on to get stuff upstream, but it seems to me that it's lagging. It's important not to get behind as it only gets harder to catch up.
[Mirv] For the most part of Touch development there is a constant flow from Canonical to Qt upstream, and most of the current patches have been integrated to Qt 5.2 (some later). However as an example the arm64 patches came in apparently without upstreaming and the appmenu was already mentioned as lagging.

This discussion is particularly timely since we think it's likely at least some elements of KDE Frameworks 5 (the Qt5 based port of kdelibs) will land in the archive during this cycle.