Am Montag, 27. August 2012, 11:27:43 schrieb Adam D. Barratt: > On 27.08.2012 08:34, Cajus Pollmeier wrote: > > Am Freitag, 24. August 2012, 18:39:28 schrieb Adam D. Barratt: > >> On Fri, 2012-08-24 at 11:00 +0200, Cajus Pollmeier wrote: > >> > Am Freitag, 24. August 2012, 10:19:45 schrieben Sie: > >> > > +- static std::auto_ptr<SaslAuthenticator> > >> > > createAuthenticator(Connection& connection, bool isShadow); ++ > >> > > static std::auto_ptr<SaslAuthenticator> > >> > > createAuthenticator(Connection& connection); > >> > > > >> > > createAuthenticator() is a public symbol of libqpidbroker, which > >> > >> is > >> > >> > > shipped as a public library in /usr/lib. That means the library > >> > >> has > >> > >> > > changed ABI without changing SONAME afaics. > >> > > >> > libqpidbroker is only used by the qpid broker itself. There's > >> > >> nothing in > >> > >> > testing that uses the broker library - besides the broker itself. > >> > Unstable has the qpidd-msgstore module that makes use of that > >> > >> library. > >> > >> qpidd-msgstore is also in testing. Does the earlier version not use > >> the > >> broker library? > > > > Hmm. Is it possible to remove it from testing? The version that > > matches the > > current 0.16 release of qpidd got stuck because it didn't compile on > > all > > architectures. 0.14 qpidd-msgstore will not work with 0.16 of qpidd. > > Okay; removal hint added. Thanks. Seems to be gone already ;-) > >> > I'm not sure if and how I can simply change the SONAME for the > >> > >> broker. > >> > >> > And if there's a need for that in this case. Any hints? > >> > >> It's shipped in a public library directory and versioned so yes it > >> should be updated (even without the existence of a reverse > >> dependency). > >> Assuming the SONAMEs come from upstream, it'd be worth discussing > >> the > >> issue with them so we don't end up carrying a Debian-specific change > >> for > >> it. > > > > Just sent a message to upstream. Lets see. > > Thanks. That's the answer: I don't think that we are currently proposing any upstream library versioning at all. As far as I remember the library versioning in the Fedora and Red Hat Enterprise packages are not the same as the versioning you will get if you just run make install on the upstream package. Similarly we've not been especially careful to change library versions consistent with ABI so I perhaps you should do whatever works for your packaging. I would note that libqpidbroker really exposes only an entirely private interface though so perhaps it's versioning isn't that significant - it's not actually separable from qpidd anyway. Andrew Which may lead to these actions: * Inspect the SONAME of the upcoming 0.18 release and choose some non conflicting value between the 0.16 and 0.18 releases. I'd like to avoid maintaining a completely different scheme on my own. The qpid packages are very time consuming even without that. * Remove these libraries from /usr/lib because they seem to be more more private - even though they're used by the msgstore component. But this may lead to complications when the msgstore component is trying to find the affected .so's without munging around with library paths. * Just leave it as it is for wheezy, because there's nothing that depends on it - and probably will never be. I'd personally prefere the latter, because there seems to be no need to care about it in this case. Additionally I cannot address these issues within the next three weeks due to holiday situations. But - of course - I'm aware that there are reasons to choose #1 or #2 for wheezy. What do you think? Would it be ok for you to just leave it as it is? Cheers, Cajus
Description: This is a digitally signed message part.