Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end up with a dependency only on
> > > the
> > > GL version of the package instead of a dependency on GL | GLES.
> 
> On a second thought: suppose a library libexample that uses the symbols as
> provided by the current libqt5gui5 (either with one or the other version)
> but does not exposes it's symbols. The end result will not make
> libexample's symbols change but will for sure it's internal usage of
> libqt5gui5. How can one differentiate libraries like libexample from other
> libraries that do use libqt5gui5 but not it's OpenGL stuff?

Or maybe even applications! Let's suppose libqt5qml5 follows the libexample 
example (it *does* requires some kind of OpenGL). Now qtcreator (to name just 
one application) does usage of it, and users will surely want to use the right 
build for their use case. Building two qtcreator binaries sounds like just too 
much.

Now get Plasma. It does a heavy usage of QML. In *lots* of places and 
packages.

At this point I really feel that, except I am missing something, double 
building is just not a good idea :-/


-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

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/fe0de41e/attachment.sig>