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

Re: Improving dependencies on shared libraries



On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote:
> On Sat, 26 May 2007, Josselin Mouette wrote:
> > Le samedi 26 mai 2007 à 22:34 +0200, Raphael Hertzog a écrit :
> > > > This is not going to work. Checking that symbols are present in a
> > > > version does not guarantee they provide the required ABI.
> > > 
> > > If the ABI changes, the soname changes. I store the information of symbols
> > > for a given soname. So it should work.
> > 
> > The soname only changes if the ABI becomes incompatible. If the ABI is
> > extended, the soname doesn't change.
> > 
> > The example I showed doesn't require a soname change.
> 
> Right, I read your message too quickly, sorry. However the maintainer
> can change the symbols file in his package and update the dependency
> associated to this symbol and make sure that a binary using this symbol
> will depend on the version used to build the package.
> 
> However it might well be some form of micro-management that you don't want
> to have to deal with. And it can't be handled automatically. How
> frequently do we encounter this kind of extension of the ABI ?

  For skilled upstreams yes it happens. Breaking ABI or doing backward
incompatbile changes suck, and clever upstream that know about libraries
do it all the time (Okay that left us only maybe 10 or 15 upstreams
match the criterium).

  Though, upstreams doing this could also I'd say use symbol versionning
and bump the version of this symbol if it behaviour changed, so that the
binary couldn't be used on an earlier version of the library by mistake,
depends on what this "extension" of the API really does.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp0s5ktcXGlx.pgp
Description: PGP signature


Reply to: