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

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

Damyan, very sorry that I have not answered your letter in the right time.

On Wednesday 18 July 2007 15:50, Damyan Ivanov wrote:

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

It's used in 3 ways:
1. As an embedded engine (including use in our standard utilities like gbak).
2. As 'traditional server' when called from fb_inet_server.
3. As a client.
How should we say which one is primary :)

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

Quite possible, but how is it related to soname?
I agree that almost all programs, that used firebird API 1.x will work just 
fine with 2.x, but program, linked with 2.1 library will not find all 
required entries in older library. But where is soname here?

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

Sorry, here I do not understand what you mean... Do you want to say that with 
long FB's release cycle changing soname manually is not a big problem?

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

Both.