[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Wow.

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.


Attachment: pgp4huY8pEUKN.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]