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

[Damyan I. <da...@mo...>]

-=| Alex Peshkov, 18.07.2007 11:05 |=-

Hi, Alex,

I hope you had a good time on your vacation :)

> 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 agree. Let's assume that primary use of libfbembed is as embedded engine.

> 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. 

Oh, that gets really interesting :)

> 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).

Debian does not need changing the soname when changes are 100%
backwards-compatible. It is normal for packages, built using (for
example) libfirebird.so version 3.0 to depend on package libfirebird
version 3.0 and above. That is, you can't downgrade the library package
and still use the same program package, because the dependency would be
broken.

I guess similar mechanism exists in other distributions too.

Actually, given a release cycle of ~1 year[1] soname change is not such
a problem even if not mandatory.

[1] That number is somewhat arbitrary. Anything over 6 months avoids too
much of a burder renaming/rebuilding packages.

> 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.

Just to be clear: you mean fbembed's soname here, not fbclient, right?


Thank you very much
-- 
dam            JabberID: da...@ja...