[Development] Tagging private symbols as such

Kevin Kofler kevin.kofler at chello.at
Thu Dec 8 02:02:36 CET 2016

Dmitry Shachnev wrote:
> I also dislike this change. As Lisandro says, we do not want it in Debian
> (because we keep track of versions ourselves in the symbols file, and when
> the versions are in the symbols themselves they are just useless noise for
> us). And as you say, you do not want distributions Qt builds to be ABI
> incompatible with upstream (we also would like to avoid that), so if this
> patch gets applied upstream, we will be in a bad situation.
> I wonder what was the reason for OpenSUSE to have this change — I could
> not find a relevant changelog entry. Why cannot they just rebuild all
> packages using private headers for every Qt release, like we do?

See my replies: RPM tracks symbol versions, but not the actual names, e.g., 
Qt has auto-Provides like:

The auto-Requires correspond. As you can see, the non-private symbols are 
properly versioned, so if something requires an API introduced in 5.6, it 
will have an auto-Requires on "libQt5Core.so.5(Qt_5.6)(64bit)", and the 
dependency solver will know to drag in qt5-qtbase-5.6.0 or newer in a 
selective update scenario (because the older versions will just not have 
that Provides).

Unfortunately, the private symbols just have a generic 
"libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit)" version, which is completely 
useless. (It is versioned as if the ABI were completely immutable, thus 
effectively unversioned.) So we are left to manually query for stuff 
requiring Qt_5_PRIVATE_API and/or manually add versioned Requires on the 
package. If the symbols instead had a version number, e.g.:
that would automatically ensure the packages drag in Qt 5.6.2 and no other 
version, without having to manually add a:
Requires: qt5-qtbase%{?_isa} = %{_qt5_version}

The difference in implementation compared to the Qt_5.x symbol versions 
would be that the private symbols would of course NOT provide the older 
symbol versions, only the latest one, making it effectively an = dependency 
rather than a >= one.

RPM explicitly does NOT track individual symbols as Debian tooling 
apparently does.

        Kevin Kofler

More information about the Development mailing list