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
Attachment:
signature.asc
Description: This is a digitally signed message part.