According to [1], icu can be used as a system-level library, maintaining binary compatibility between versions, if it's compiled with "--disable-renaming". I'm not fully aware of the implications of enabling or disabling function renaming, so this is more a proposal than an actual bug and might require a bit of discussion. [1] http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library
--disable-renaming option does not affect filenames and sonames of libraries, so rebuilding of reverse dependencies would be still required after upgrading/downgrading major version of ICU. It does not matter if functions are internally renamed in libraries. I suggest to close this bug.
Oh yes it matters. If the functions are called foo_48, foo_49, etc... (where the _XX suffix is the version of icu) like it's happening now in gentoo, users of these libraries cannot use dlsym() to dynamically load their symbols, because the version suffix cannot be reliably known in advance. --disable-renaming suppresses that version suffix, making it possible to use dlsym("foo"). And since dev-libs/icu is not slotted, what's the point in "versioning" its symbols?
ping! I'd like to reach consensus on a resolution as soon as possible. Any arguments against --disable-renaming?
Such a change in given major version of ICU would be an incompatible change not detectable by revdep-rebuild, so it must be deferred to ICU 50.
That's true, however we could tell our users to rebuild all reverse deps via an ewarn message... we're talking about ~arch here after all. Note that an ewarn should already be added for the qt-core issue (bug 413541) if we keep the status quo for icu-49, which would be avoided by disabling renaming, so we're basically trading one ewarn for another ewarn, with the "small" difference that one of them is going to hit stable users. I'd like to hear the opinion of some other maintainers too.
(In reply to comment #5) > That's true, however we could tell our users to rebuild all reverse deps via > an ewarn message... Regarding this, we have already broke stable systems, we should release a news item telling people to rebuild qt-core and libxml2, the problem is that I don't know if more random packages are affected :S >we're talking about ~arch here after all. > > Note that an ewarn should already be added for the qt-core issue (bug > 413541) if we keep the status quo for icu-49, which would be avoided by > disabling renaming, so we're basically trading one ewarn for another ewarn, > with the "small" difference that one of them is going to hit stable users. > > I'd like to hear the opinion of some other maintainers too. About this, looks like there are no cons to disable renaming in icu-50... I would go for it
(In reply to comment #6) > Regarding this, we have already broke stable systems, we should release a > news item telling people to rebuild qt-core and libxml2, the problem is that > I don't know if more random packages are affected :S To be clear: the qt-core issue did not break any systems. It simply caused a warning message to be displayed until qt-core was rebuilt.
(In reply to comment #7) > (In reply to comment #6) > > Regarding this, we have already broke stable systems, we should release a > > news item telling people to rebuild qt-core and libxml2, the problem is that > > I don't know if more random packages are affected :S > > To be clear: the qt-core issue did not break any systems. It simply caused a > warning message to be displayed until qt-core was rebuilt. Some dupes of bug 413541 disagree. It seems that cmake or automoc were actually broken by this, and this implies that most cmake-based packages couldn't be emerged. Furthermore, ago reported that calligra failed to start until he rebuilt qt-core. So.. yes, there has been real breakage in the stable tree.
(In reply to comment #8) > Some dupes of bug 413541 disagree. It seems that cmake or automoc were > actually broken by this, and this implies that most cmake-based packages > couldn't be emerged. Furthermore, ago reported that calligra failed to start > until he rebuilt qt-core. So.. yes, there has been real breakage in the > stable tree. I don't think qt-core had anything to do with that. It looks like libxml2 broke, which broke cmake. I think revdep-rebuild detects the breakage in libxml2, but emerge screws up the merge order. Any time you change soname on a library, stable systems will break. The only thing that makes this special is that we seem to have some missing or circular deps which cause revdep-rebuild to fail.
Function renaming hath been disabled in dev-libs/icu-50_rc.
