Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
On Wednesday 16 December 2015 17:42:29 šumski wrote: > On Wednesday 16 of December 2015 09:08:03 David Faure wrote: > > Fixed, it was an oversight when converting the lib into a KF5 framework. > > But this is a BiC change... One that is generally allowed (not like removing a virtual method and NOT upgrading the so number) but which indeed creates more work for packagers (need to ship the old as well as the new lib, so that apps linking to the old lib keep working). -> reverted, not worth the trouble. Thanks for the note. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
On Thursday 17 of December 2015 12:51:42 René J. V. Bertin wrote: > šumski wrote: > >> Yes, bug fixes can do that ;) > > > > Yes, but frameworks are under BC guarantee. > > So how are bugs supposed to be fixed if they break ABI compatibility? Certainly not by breaking one of core policies. > > If I'm not mistaken Linux will not check beyond shared library file names. > If that's correct, the build system can install a libKF5FMD.so.3 file that > links to libKF5FMD.so.5 then applications that haven't been relinked > should load and run. > > This isn't a typical version of ABI breakage, btw. And I have a hunch that > users who build from source won't even notice the change because > libKF5FMD.so.3 and libKF5FMD.so.5.16.0 will not be uninstalled when you > install KFileMetaData 5.17.0 . It will be different for users who get > their binaries from an upstream packager/distribution ... and it'll be > trivial for those to provide relinked dependent packages. (MacPorts will > scan for and pick up this kind of change, queuing affected dependents for > a rebuild; I cannot imagine that Linux packaging systems do not have such > a convenience feature.) That's not relevant at all. Yeah it can we workarounded though i don't think fixing a cosmetic bug is better than introducing a grave bug. Cheers, Hrvoje > > R. > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
šumski wrote: >> Yes, bug fixes can do that ;) > Yes, but frameworks are under BC guarantee. So how are bugs supposed to be fixed if they break ABI compatibility? If I'm not mistaken Linux will not check beyond shared library file names. If that's correct, the build system can install a libKF5FMD.so.3 file that links to libKF5FMD.so.5 then applications that haven't been relinked should load and run. This isn't a typical version of ABI breakage, btw. And I have a hunch that users who build from source won't even notice the change because libKF5FMD.so.3 and libKF5FMD.so.5.16.0 will not be uninstalled when you install KFileMetaData 5.17.0 . It will be different for users who get their binaries from an upstream packager/distribution ... and it'll be trivial for those to provide relinked dependent packages. (MacPorts will scan for and pick up this kind of change, queuing affected dependents for a rebuild; I cannot imagine that Linux packaging systems do not have such a convenience feature.) R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
šumski wrote: >> Fixed, it was an oversight when converting the lib into a KF5 framework. > > But this is a BiC change... Yes, bug fixes can do that ;) R ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
On Wednesday 16 of December 2015 09:08:03 David Faure wrote: > Fixed, it was an oversight when converting the lib into a KF5 framework. But this is a BiC change... Cheers, Hrvoje ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
Fixed, it was an oversight when converting the lib into a KF5 framework. > On Tuesday December 15 2015 18:55:52 René J.V. Bertin wrote: > > for packaging purposes it would be preferable if all libraries (symlinks) > > that are recorded in dependents' dependency lists are of the form > > libKF5*.5.dylib or libKF5*.so.5 (KFileMetadata is the only deviant one). Not exactly, there's also ../bluez-qt/CMakeLists.txt:27:SOVERSION 6 ../kactivities/CMakeLists.txt:129: SOVERSION 1 ../modemmanager-qt/CMakeLists.txt:40:SOVERSION 6) ../networkmanager-qt/CMakeLists.txt:40:SOVERSION 6) > PS : KDE4's kfilemetadata has a compatibility/so version 4 ... Doesn't matter, it had a different library name (no KF5 in the name). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
On Wednesday December 16 2015 09:08:03 David Faure wrote: > Fixed, it was an oversight when converting the lib into a KF5 framework. Hah, you're welcome O:-) I had already taken the liberty to apply it myself (setting SOVERSION to 5); good to know it'll be part of the next release. > ../bluez-qt/CMakeLists.txt:27:SOVERSION 6 > ../kactivities/CMakeLists.txt:129: SOVERSION 1 > ../modemmanager-qt/CMakeLists.txt:40:SOVERSION 6) > ../networkmanager-qt/CMakeLists.txt:40:SOVERSION 6) I'm seeing a .5.dylib / .so.5 extension on libKF5Activities on my end; the others I didn't even try to build to satisfy dependencies (not supposed to work on OS X; I might need to add them for Linux though). > > PS : KDE4's kfilemetadata has a compatibility/so version 4 ... > > Doesn't matter, it had a different library name (no KF5 in the name). Matter or not, I found it surprising that the version number had decreased w.r.t. the KDE4 implementation. Note that the so/compatibility version doesn't only enter in the file name on OS X. It's also stored in the library itself, and the dynamic loader will reject a correctly named shared library that has a too-recent compatibility version. So the fix will force a rebuild on all dependents on OS X; simply providing a symlink so the .3.dylib file resolves to the correct library won't work. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
Out of curiosity: is it intended that KFileMetaData sets the library compatibility version to 3, leading to /opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so /opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so.3 /opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so.5.17.0 and on OS X %> otool -L /opt/local/lib/libKF5FileMetaData.3.dylib /opt/local/lib/libKF5FileMetaData.3.dylib: /opt/local/lib/libKF5FileMetaData.3.dylib (compatibility version 3.0.0, current version 5.17.0) /opt/local/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, current version 5.17.0) /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, current version 5.5.1) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) for packaging purposes it would be preferable if all libraries (symlinks) that are recorded in dependents' dependency lists are of the form libKF5*.5.dylib or libKF5*.so.5 (KFileMetadata is the only deviant one). Thanks, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib
On Tuesday December 15 2015 18:55:52 René J.V. Bertin wrote: > for packaging purposes it would be preferable if all libraries (symlinks) > that are recorded in dependents' dependency lists are of the form > libKF5*.5.dylib or libKF5*.so.5 (KFileMetadata is the only deviant one). PS : KDE4's kfilemetadata has a compatibility/so version 4 ... R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
