On Fri, 2012-11-02 at 11:39 -0400, Darryl L. Pierce wrote: > In going through the packaging for Fedora, I found a disconnect between > the soversions for our libraries as declared in the build systems in our > repo and what Fedora is assigning to each. I bumped the versions in > CMake to match what's declared in Fedora and pushed before raising the > issue here. > > What we had previously was: > > LIBRARY IN REPO FEDORA > ------------- -------- ------ > qmf 1.0.0 4.0.0 > qmf2 1.0.0 1.0.0 > qmfconsole 2.0.0 5.0.0 > qmfengine 1.1.0 4.0.0 > qpidbroker 2.0.0 5.0.0 > qpidclient 2.0.0 5.0.0 > qpidcommon 2.0.0 5.0.0 > qpidmessaging 2.0.0 4.0.1 > qpidtypes 1.0.0 3.0.2 > rdmawrap 2.0.0 5.0.0 > sslcommon 2.0.0 5.0.0
My recollection of previous discussions is this (someone else might have a better recollection): Nearly all of those libraries are purely for internal use in qpid executables/libraries and are not meant to be exposed to developers to link against. Ideally these libraries wouldn't even be in /usr/lib[64] at all. This includes qpidbroker, qpidcommon, rdmawrap, sslcommon. I'm not sure about the various qmf libraries, but I think only qmf2 is current anyway. Since these are purely internal the soversion is irrelevant since we make absolutely no ABI guarantee at all - in fact it would make sense not to include soversions as you HAVE to use the library that you compiled for the version of qpid you are using. qpidclient is a possible exception to the above in that, ideally it is a purely internal library now, only being used in the implementation of the qpidmessaging API and deprecated for direct use. However even there it is clear that the qpid upstream has not changed the so version. And it looks like Fedora has revved the number just once for incompatible changes to the API/ABI. This makes me think that no one s really paying attention to the library compatibility for this library. The only libraries which are presently intended to have a stable API and therefore a controlled ABI are qpidmessaging and qpidtypes as far as I know. For these libraries and I think for these ones only we do need to manage the soversions a little carefully with respect to interface changes. So after all that long winded explanation here is the TL:DR: There are a few possibilities - * [My preferred option] The qpid upsteam should not worry about soversions AT ALL and leave it for downstream to get right. In this case we just leave the soversions as they are "forever" and downstream needs to patch them as necessary. This is the current status. * We unversion the internal only libraries to avoid the suggestion that the soversion might indicate something for them. If possible we move the libraries away from /usr/lib[64] to stop them being visible for developers linking against them. We then rev the qpidmessaging/qpidtypes soversions to something higher than everyone is currently using to indicate a break of compatibility and we start carefully enforcing soversion bumps when we make non backward compatible ABI changes (and minor bumps when we make any change). Major problem here is that we don't have upstream tools (that I know about) to warn us of any ABI changes. Downstreams have some tools for this though. So enforcing the version bumps will be hit and miss. -- Justin as release manager through the past few releases do you have any thoughts to add? Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
