On Thu, May 9, 2013 at 3:28 PM, Peter Humphrey <pe...@humphrey.ukfsn.org> wrote:
> I'm puzzled by the following, which I checked to compare with the import
> error you quoted:
>
> $ eix -c qtwebkit
> [I] dev-qt/qtwebkit (4.8.4(4){tbz2}@08/05/13): The WebKit module for the Qt
> toolkit
>
> $ equery f qtwebkit | grep '.so.'
> /usr/lib64/qt4/libQtWebKit.so.4
> /usr/lib64/qt4/libQtWebKit.so.4.9
> /usr/lib64/qt4/libQtWebKit.so.4.9.3
>
> $ qfile /usr/lib64/qt4/libQtWebKit.so.4.9.3
> dev-qt/qtwebkit (/usr/lib64/qt4/libQtWebKit.so.4.9.3)
>
> Why the mismatched version numbers, anyone?The soname version number does not necessarily have to be the same as the release version, as you see in this case, it's actually somewhat common. MOST packagers try to keep them the same but there's no technical reason for them to be. Most noticeably I see a lot of KDE-related packages having so versions that differ from the release version. In this case I guess it is because QtWebkit kind of exists on its own, despite being part of Qt proper since 4.8-ish. Probably QtWebKit interface changes are happening on a different schedule than Qt version releases so they have to keep bumping the so version? Maybe somebody with more knowledge of Qt would know for sure.
