Re: [Firebird-devel] library soname for fbclient and fbembed

[Alex P. <pes...@ma...>]

On Tuesday 26 June 2007 15:01, Damyan Ivanov wrote:
> Since libfbclient is guaranteed to be 100% backwards-compatible[1] (as I
> understand it), there's no need to change its soname. As we now already
> have libfbclient.so.2, let's keep that in 2.1 too. In other words, no
> change is required for fbclient, FB 2.1 can safely contain
> libfbclient.so.2.1.0, with soname of libfbclient.so.2 and symlinked from
> libfbclient.so.2.
>
> libfbembed, however, is another case -- as I understand it, its
> behaviour changes with each major release (and *possibly* with minor
> ones too) -- new datatypes, syntax construct, etc.
>
> Imagine a program that uses libfbembed as embedded server -- it relies on
> certain behaviour of the server and this should not change unexpectedly
> because the progam will break.
>
> fb_inet_server is another (although different) case - it is supposed to
> offer connection to a certain version of the server. If I have
> fb_inet_server from 2.0, connecting to it should offer the functionality
> of FB 2.0.
>
> To address the problem, I propose usage of soname for libfbembed that
> changes when "behaviour" of the server changes. I suppose this means
> soname of libfbembed.so.2.1 for FB 2.1.0. If there are behaviour changes
> in 2.1.x (x>0) then the soname may need to include that "x" too.
>
> This way, program linked with libfbembed.so.2.1 will continue to work as
> before even if FB 3.0 (or any other) is installed, since the library
> file will be named differently in 3.0 and will not replace the previous
> one.

Reviewing your suggestions (selection of good so names for firebird is 
definitely NOT trivial thing) I may suppose that they are almost OK for fb2. 
Why almost - libfbembed is not only an embedded server. It's also the 
full-featured client for non-MT applications. And when used in that way 
should behave exactly the same way as fbclient does. Certainly, we can't 
assign different sonames for same library depeneding upon how does client 
plan to use it :)

I can agree that suggested by you compromise may be used for fb2. But we are 
going to have correct sonames in the fiture too, yes? And here we get an 
interesting case - there will be no different libraries for embedded server 
and client at all in FB3. Only single universal libfirebird.so, which which 
will invoke (using dl) appropriate engine or network redirector or (as a 
sample) special library, serving as a proxy with MySQL. YValve's architecture 
makes all of this possible. 

It seems to me that the only thing which makes sense to be controlled by 
soname in such a case should be API version, provided by firebird library. We 
never used to incompatibly modify old API calls (and hope will not have to do 
it in the future), but sometimes new calls may be added. Suppose it will be 
reasonable to change soname at this points (not to let newer programs use old 
client). And I see no reasons why not to use this approach starting with 
2.1 - at least we will not have to change our solution with next version.