Bug#802710: musescore: Embeds Qt5's private headers without putting them in a namespace

[Sebastian Ramacher]

Hi

On 2015-10-22 16:09:22, Lisandro Damián Nicanor Pérez Meyer wrote:
> Source: musescore
> Version: 2.0.2+dfsg-1
> Severity: important
> 
> Hi! While doing qt5's qtbase's private headers transition we noted that musescore
> got into the list of packages that needed a transition [lop] but without
> build depending on qtbase5-dev.
> 
> [lop] <https://release.debian.org/transitions/html/qtbase-abi-5-5-1.html>
> 
> My teammate Dmitry Schanev found out that musescore ships a Qt5 private header:
> 
> <http://sources.debian.net/src/musescore/2.0.2%2Bdfsg-1/thirdparty/xmlstream/xmlutils_p.h/>
> 
> By building this header without a namespace the symbols that it generates matchs the symbols
> of qtbase's private stuff, so unnecesarily being part of transitions like this.

The xmlstream stuff is not the problem. They are not unresolved symbols and do
not cause a dependency on qtbase-abi-5-5-1. They probably clash with the symbols
from Qt, but that's easy to fix with a namespace or renaming the copy of
QXmlUtils.

Looking at the output of dpkg-shlibdeps with -v -v shows the actual problem:
|  Looking up symbol _ZN12QPaintEngineC2ER19QPaintEnginePrivate6QFlagsINS_18PaintEngineFeatureEE at Base
|  Found in symbols file of libQt5Gui.so.5 (minver: 5.0.2, dep: libqt5gui5 #MINVER#, qtbase-abi-5-5-1)

This might be caused by mscore/paintengine_p.h and mscore/svgenerator.* where
the QPaintEngine and QPaintEnginePrivate are used.

Cheers
-- 
Sebastian Ramacher