GNOME Bugzilla – Bug 684455
soname bump in stable glade 3.12.2?
Last modified: 2013-09-11 22:17:12 UTC
Hello, The NEWS file for glade 3.12.2 mentions "New release to fix libtool version (bumped current to 2)" and indeed, the libgladeui soname goes from libgladeui-2.so.0 to libgladeui-2.so.2. Is this change deliberate? Because if it is, it pretty much means distros won't be picking up 3.12.2 in their stable updates repo. Without the soname bump, Fedora 17 would have gotten 3.12.2 to replace 3.12.1, but needing to rebuild dependant packages leaves it out of the question. P.S. The soname bump in 3.14.0 is perfectly fine, it's still easy to rebuild dependencies in a distro under development, like F18.
Kalev, This downside was certainly not deliberate but the change was. Honestly, I'm replying right now without all of the hard facts but I do know we had been already experiencing some fallout in the previous release. Basically the last release had been made without a proper understanding of the libtool versioning numbers, leaving a situation where (if i understand correctly) installing the new version from the sources would not override the previous version already installed in $(prefix)/lib[64] (so you would run 'make install' and then wonder why you didnt get any update). Honestly we work much more closely to people who install from git or at least build by hand (so we had a series of reported problems from this last error, which we were trying to address with this "fix"). Its a bit of a mess this situation, I would of course like to offer to roll a separate release for the sake of distros picking that up but, with all these libtool version numbers flying around it's perhaps safer to just let it be and try to do better in the future. It is unfortunate though to not be able to push bugfixes out on the 3.12 branch...
Hello, I can see how this is a problem for file based distributions. But this was something that had to be addressed. Maybe you could bump revision instead, but in any case that would be a distro patch.
Alright, let me try to see if I understand it right. You've now decided to strictly follow the libtool versioning rules, as documented in configure.ac: > # If the source code has changed at all, increment GLADE_REVISION > # If any interfaces have been added, removed, or changed, increment GLADE_CURRENT, and set GLADE_REVISION to 0. > # If any interfaces have been added since the last public release, then increment GLADE_AGE. > # If any interfaces have been removed since the last public release, then set GLADE_AGE to 0. > # Reference: http://www.gnu.org/software/libtool/manual.html#Versioning ... and following the rules above, when doing the 3.12.2 release you figured that "interfaces have been added, removed, or changed" and incremented GLADE_CURRENT, and set GLADE_REVISION to ?
> 16:36 < tristan|zzZ> kalev, we messed up libtool versioning :( > 16:40 < tristan|zzZ> kalev, if you want to ... really ... wrap your brain around the libtool mess in 3.12... and really find a way to release a 3.12 that will a.) get picked up by distros and b.) not collide with future versions/releases... be my guest and present your tactics/patches on the ML So here's my analysis, posting them here instead of the ML just to keep the discussion at one place. First, I believe it's important to keep the ABI changes out of the stable release branches so that distros could pick up the new versions. There are several apps that use glade libs, and the distros don't want to rebuild all of them in their stable releases. Second, the libgladeui soname should only change if the library ABI changes. And that shouldn't happen in the stable branches. It's fine to change the symbols that are exported from the internal plugins, as they only get loaded internally by Glade. But not libgladeui; this is what other apps link with. Third, I see no ABI changes whatsoever in libgladeui between 3.12.1 and 3.12.2, which makes the soname bump unnecessary: $ git diff GLADE_3_12_1..GLADE_3_12_2 -- gladeui So the fix for glade 3.12.x releases would be, in my opinion, to just revert back to the old soname: -GLADE_CURRENT=2 +GLADE_CURRENT=0 With my Fedora packager hat on, this will be enough to get it picked up in Fedora 17. The soname in 3.14.x already differs from what we have in glade 3.12, so it can't really collide in any way with future releases.
Closing this bug as obsolete sine we are about to release 3.16 now