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:
pgpgLuVGv3JjH.pgp
Description: PGP signature