GNOME Bugzilla – Bug 583825
soversion NEVER changed
Last modified: 2009-05-28 17:21:29 UTC
libxml++ introduced an ABI breakage to fix a serious bug: http://git.gnome.org/cgit/libxml++/commit/?id=4ff42fba42e3f89986d30231a4e8e604592c8fff But then the soversion NEVER changed. This is bad.
*** Bug 583807 has been marked as a duplicate of this bug. ***
*** Bug 583808 has been marked as a duplicate of this bug. ***
That ABI was broken because nobody could be using it, so there's no need to warn people of any ABI change. We don't generally change the .so version because then we'd have to change it during unstable development releases, which would then indicate ABI breaks between stable releases, when there are none.
Furthermore, handling this like a real ABI change would require a parallel install. And that really would create difficulties for people actually using the large part of the ABI that has definitely not broken by any interpretation.
(In reply to comment #3) > That ABI was broken because nobody could be using it, so there's no need to > warn people of any ABI change. Whether the API that was changed, breaking the ABI, was used is not the issue (although it is clear that it was not used, as it was broken). The issue is that dynamically-linked applications (well, the dynamic linker) cannot use the soversion as a means to test for this ABI change. This is what the soversion is designed for, so at the very least, it is not being used correctly here. For example, http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info has not been followed for this release, as the "current" version has not been incremented, following an ABI-incompatible change. > We don't generally change the .so version because then we'd have to change it > during unstable development releases, which would then indicate ABI breaks > between stable releases, when there are none. The Libtool manual (see above) recommends only bumping the version before a public release. I quote: "More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster." It is possible to update both "revision" and "age" sections of the soversion while maintaining backwards-ABI compatibility, according to the Libtool manual, which would be the case for adding API and not changing or removing it in a way that breaks ABI. I think that is is important for this change to cause an increment in the "current" part of the soversion, thus indicating an ABI-incompatible change, as this is precisely the intent of the soversion. Yes, it is unpleasant to break the ABI for a change such as this, where the API was broken before the change, but it is ABI-incompatible nonetheless. (In reply to comment #4) > Furthermore, handling this like a real ABI change would require a parallel > install. And that really would create difficulties for people actually using > the large part of the ABI that has definitely not broken by any interpretation. Yes, but not changing the soversion when the ABI changes also creates difficulties. This is especially the case on source-based distributions. It may be acceptable to expect binary-based distributions to depend on a specific package version (and not soversion), but in a source-based distribution where the ABI changes without a soversion change, breakage results.
As long as the ABI was not being used, I see no problem with breaking it. Unfortunately, Hub was using it, but obviously not yet in any serious way. His slight disadvantage in this case is not much compared to the huge disadvantage of signalling a whole ABI break. Simply following the instructions for changing soversion does not help us with the unhelpful problems with changing soversion, which is why it's so often not used. None of this is helpful to anyone so I'm closing it as WONTFIX.
Is there a way to determine whether a specific application is subject to this issue? We’d like at least to handle things correctly at the distribution level by adding proper conflicts.
Josselin, it's anybody using the TextReader API from libxml++.
I was. And as long as there was no error 2.24 was OK. Someone built 2.26, installed on his system. Then Gnote was not recompiled and reported me the crashes (see the 2 duplicates). If you don't want an API to be used, don't install the header. Reopening.
No, really, closed. I'm sorry that you experienced this problem, but it doesn't change our reasoning.