Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi Steve!

First of all: thanks for chiming in!

El martes, 27 de noviembre de 2018 19:06:27 -03 Steve Langasek escribió:
> Hi Lisandro,
[snip]
> > This waterfall schema means *multiple* libraries would have to start doing
> > this two-binaries thing, as Ubuntu devs discovered. But remember that Qt
> > is
> > really a set of submodules, so in any later version any submodule could
> > start using this switch for something. So whatever change could mean yet
> > another set of binaries with a transition with multiple rebuilds of the
> > big part of rdeps of Qt... no, we don't want to enter that mess.
> 
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> 
> Yes, GL vs. GLES impacts the ABI of libqt5gui5; HOWEVER, the set of
> reverse-dependencies that are actually impacted by the GL-specific ABI
> difference is actually quite small; and by using clever symbols files, the
> impact on the dependency tree can be minimized.
> 
> If anyone wants to dig into this further, perhaps for proof-of-concept, here
> is packaging that could be used as a starting point for the symbols files:
> 
>  
> https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg-> 2ubuntu4~1
> 
> And here is the list of all packages that required dual-stack at least as of
> 2017, when Ubuntu stopped development on this:
> 
> $ wget -O - -q
> http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.g
> z \ zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
> Package: qt3d-opensource-src-gles
> Package: qtbase-opensource-src-gles
> Package: qtdeclarative-opensource-src-gles
> Package: qtlocation-opensource-src-gles
> Package: qtmir-gles
> Package: qtmultimedia-opensource-src-gles
> Package: qtubuntu-gles
> $
> 
> i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
> qtubuntu).

And to be honest two of those packages where exclusive to ubuntu: qtmir-gles 
and qtubuntu-gles.

> Maybe you were already aware of this, but it didn't come across to me in
> your mail, sorry. 

Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt 
maintainer). He points me out that those 7 packages were needed for the Ubuntu 
Touch port which, I presume, does not counts KDE's Plasma or KF libraries. The 
question is then: how would this affect other stacks like the ones I mentioned 
before? And then there might be other libraries involved. Granted, we do not 
know exactly which ones but...

> If you still think it is too much maintenance overhead to
> provide a dual stack for these 5 libraries (plus any others that later
> start to use GL-dependant ABIs), I think you're absolutely entitled to that
> view.

..yes, we are a team of roughly 3 people, mostly not available the three at 
the same time. It is not a strange situation that *just* one of us prepares 
almost (if not all) the full stack when a new release happens and sometimes 
even one of the others gets to handle the transition needed for private 
symbols (and thus getting it into unstable properly).

We are indeed having help from new contributors in some points, and I really 
hope they step up even more in the future, but currently the stack is huge for 
us. Heck, we don't even manage to handle tests for some submodules, let's not 
even think on autopkgtests.

But then let's suppose new manpower arrives, maybe dedicated to the task. The 
question is then: how many other packages this will affect? Will all the other 
maintainers be able to handle double stacks if needed? Is it really good to 
"kind of" impose even more work to maintainers? The KDE-related stack is 
possibly even bigger than Qt, and to the best of my knowledge there are just a 
handful of people maintaining it.

My current answer is: I really don't know.

-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20181127/1bfef3fa/attachment-0001.sig>