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