On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> 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 :-/
Ok, I don't think you've understood then. Perhaps a further example from
the Ubuntu archive would help. As of Ubuntu 16.04, here is the *complete*
list of packages that had a hard dependency on any of the 5 GL-linked Qt
libraries, where that dependency could not instead be satisfied by the GLES
build:
$ grep-dctrl -n -sSource:Package -FDepends \
-e 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>= 5\.[0-9.]*\))(?|$),' \
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages | sort -u
maliit-plugins
ovito
pyqt5
qml-box2d
qt3d-opensource-src
qtbase-opensource-src
qtdeclarative-opensource-src
qtubuntu-cameraplugin-fake
stellarium
wallch
$
Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu
16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles.
Three of the results in this list are familiar; they were already in the set
of dual-stack libraries.
Several are applications (ovito, stellarium, wallch), and if they say they
require full GL, that's legitimate, and that just means users would only be
able to install them on systems using the full desktop GL. (That's fine,
and certainly better than not being able to build/install them at all.)
maliit-plugins is not an application, but it's a rather specialized
component with no reverse-dependencies (i.e. not a library).
qml-box2d is likely to have never been uploaded after the symbols handling
was implemented in Ubuntu, therefore never picked up the alternate
dependencies (the package isn't in Debian, anyway).
And pyqt5, since it's language bindings for the full Qt API, would also need
to be double-built (but had not been in Ubuntu).
The qml packages built from these libraries - qml-module-qtlocation,
qml-module-qtmultimedia, qtdeclarative5-qtlocation-plugin - would also need
proper handling, but the impact on dependency graphs should be similarly
self-limiting; because just as for C programs, the vast majority of QML
applications don't care about the distinction between GL and GLES backends
and *expect* Qt to abstract this away for them.
So based on this, Ubuntu missed exactly one package in order to fully
support both GL and GLES builds of Qt, bringing the total to 6 instead of 5.
There might be more now, but I'd be surprised if the total number of
affected source packages in Debian today reached double digits; and in any
case the question lends itself to the same sort of analysis as above, so
anyone interested in doing this in Debian can reasonably work out the scope.
And each of those gles source packages is a purely mechanical transformation
of the base Qt source package.
So perhaps someone in this thread is willing to put in this effort to
maintain 6 source packages, in order to avoid having to make a choice
between GL and GLES on arm64.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature