Hi Steve and all, On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote: > It is actually fairly easy to answer this question as well: simply identify > all the packages in the archive that depend on one of the known dual-stack > libraries, 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. > > A fair amount of compile time required to do this analysis, but relatively > little human time. Let me explain what the mentioned “symbols file magic” is: debian/libqt5gui5.symbols header has these lines: libQt5Gui.so.5 libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#, qtbase-abi-5-7-1 | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# So symbols that exist in both desktop OpenGL and GL ES builds get a dependency on libqt5gui5 | libqt5gui5-gles, and maybe on a -abi- virtual package if they are private. And symbols that exist in only one of flavours are getting the dependency only on the particular binary package name, e.g.: (optional)_ZN25QOpenGLFunctions_3_2_Core14versionProfileEv@Qt_5 5.2.0 2 → gets a dependency on libqt5gui5 only (optional|arch=!armhf !arm64 !armel)_ZN20QOpenGLFunctions_ES214versionProfileEv@Qt_5 5.2.0 3 → gets a dependency on libqt5gui5-gles only Most of these symbols are for QOpenGLFunctions* classes. I will try to get an estimate of how many package are using them a bit later. Also there are packages that build different things depending on OpenGL variant, by using qtConfig(opengles2) in their .pro files or by checking QT_OPENGL_ES macro in their C++ files. These will probably also need dual stack packages. -- Dmitry Shachnev
Attachment:
signature.asc
Description: PGP signature