Wow.

Ewan Mac Mahon ewan at macmahon.me.uk
Thu Oct 9 22:08:03 UTC 2008


On Tue, Oct 07, 2008 at 08:38:43PM -0700, john wendel wrote:
> Kevin Kofler wrote:
>>
>> If packages A and B both depend on library L and if Rawhide has a newer 
>> version of L with a different soname major version (the number which 
>> indicates which versions of a library are binary-compatible with each 
>> other), 
>
> Isn't it possible to have multiple versions of a library installed? This  
>  would let you install A and L.new and keep B and L.old, and everything  
> should be fine. Or am I just confused? Is this a limitation of RPM or  
> just a problem with the way things get packaged?
>
It's more like policy than a problem. Libraries have two interfaces of
interest, their API (Application Programming Interface) and their ABI
(Application Binary Interface). In a nutshell the API is a source code
interface, the ABI a binary. Often a package will be updated in a way
that changes it's ABI, meaning that thing built against it won't work
any more, but without changing the API. In that case the broken apps can
be fixed simply by rebuilding them against the newer version of the
library. That's easily done, so it's not worth carrying multiple
versions of the library. 

Sometimes the API changes, and applications need source changes to work
with the new version, sometimes they're minor source changes, and
sometimes it's a major upheaval. In that case it may be worth carrying
two versions of the library; for example Fedora has gtk+ and gtk2+.

The best way of pulling in something like a newer Subversion from
rawhide onto an F9 system is generally to ignore the binary RPM and grab
the src.rpm source code package and rebuild it against the libraries on
the target distribution. That often works straight off, sometimes needs
a bit of work.

Ewan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20081009/3d5c4df6/attachment-0001.sig>


More information about the fedora-list mailing list