firebird-devel

[Firebird-devel] library soname for fbclient and fbembed

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

Hi,

The posix builds currently use the following sonames:
	file			soname
	libfbclient.so.2.1.0	libfbclient.so.2
	libfbembed.so.2.1.0	libfbembed.so.2

These are exactly the same as in firebird 2.0.

Are these libraries 100% backwards-compatible with libfb*.so.2.0.1? In
other words, is it guaranteed, that a program linked with 2.0.1 library
will continue to work as before if that library is replaced with 2.1.0
one?

As an extreme example, imagine fb_inet_server from 2.0 and libfbclient
from 2.1.

If the answer is no, then in my understanding the soname should be
changed.
-- 
dam            JabberID: da...@ja...

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

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

-=3D| Damyan Ivanov, Sat, 9 Jun 2007 16:58:45 +0300 |=3D-
> Hi,
>=20
> The posix builds currently use the following sonames:
> 	file			soname
> 	libfbclient.so.2.1.0	libfbclient.so.2
> 	libfbembed.so.2.1.0	libfbembed.so.2
>=20
> These are exactly the same as in firebird 2.0.

Additional comment:

Since the library filename is the same as its soname, installing
libfbembed from both 2.0 and 2.1 becomes impossible. This may be
considered a feature, of course, but still fb_inet_server from 2.0 and
libfbembed from 2.1 looks a little bit strange to me.
--=20
dam            JabberID: da...@ja...

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

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

On Wednesday 13 June 2007 11:22, Damyan Ivanov wrote:
> -=| Damyan Ivanov, Sat, 9 Jun 2007 16:58:45 +0300 |=-
>
> > Hi,
> >
> > The posix builds currently use the following sonames:
> > 	file			soname
> > 	libfbclient.so.2.1.0	libfbclient.so.2
> > 	libfbembed.so.2.1.0	libfbembed.so.2
> >
> > These are exactly the same as in firebird 2.0.
>
> Additional comment:
>
> Since the library filename is the same as its soname, installing
> libfbembed from both 2.0 and 2.1 becomes impossible. This may be
> considered a feature, of course, but still fb_inet_server from 2.0 and
> libfbembed from 2.1 looks a little bit strange to me.

Used in firebird naming of libraries does not match one traditionally used in 
linux. As far as I understand, soname is changed traditionally when newer 
version becomes unusable by programs, linked with old one. 

In firebird soname is blindly copied from firebird version major. I do not 
have ready idea, how to:
- do not change soname until major API change takes place (actually 
fbclient2.1 can be safely used instead of fbclient 1.0 and all versions 
between them),
- and make internal firebird binaries always use there own version of 
libraries at the same time.

Dam, if you have some suggestions - welcome, let's discuss them.

Alex.

BTW, with fb_inet_server from 2.0 and libfbembed from 2.1 you get exactly 2.1 
version server - fb_inet_server is just a tiny wrapper which calls 
server_main() from the library.

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

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

Sorry for the late reply. I was busy and the question is not exactly
easy either :)

On Fri, Jun 15, 2007 at 01:45:54PM +0400, Alex Peshkov wrote:
> Used in firebird naming of libraries does not match one traditionally used in 
> linux. As far as I understand, soname is changed traditionally when newer 
> version becomes unusable by programs, linked with old one. 
> 
> In firebird soname is blindly copied from firebird version major. I do not 
> have ready idea, how to:
> - do not change soname until major API change takes place (actually 
> fbclient2.1 can be safely used instead of fbclient 1.0 and all versions 
> between them),
> - and make internal firebird binaries always use there own version of 
> libraries at the same time.
> 
> Dam, if you have some suggestions - welcome, let's discuss them.

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.


If there are no objections, I can try to prepare a patch for the build
system.

[1] meaning that API/ABV/behaviour of the library does not change
incompatibly and programs using libfbclient from 2.0 will continue to
work as before when libfbclient from 2.1 is installed.
-- 
dam            JabberID: da...@ja...

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

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

-=| Damyan Ivanov, Tue, 26 Jun 2007 14:01:56 +0300 |=-
> If there are no objections, I can try to prepare a patch for the build
> system.

Please find attached a patch that changes the posix build system as
follows:

- the soname of fbclient is fixed to libfbclient.so.2; the actual
library file is libfbembed.so.2-$FullVersion and libfbclient.so.2 is a
symlink to that.

- the soname of fbembed is libfbembed.so.$Major.$Minor; the actual
library file is libfbembed.so.$FullVersion and
libfbembed.so.$Major.$Minor is a symlink to that.

I have also tried to adapt the install scripts.


Note that as far as I can tell, nothing is changed for non-posix builds.


Please consider applying this patch before the final release.
Applies cleanly to today's CVS HEAD.
-- 
dam            JabberID: da...@ja...

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

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

-=3D| Damyan Ivanov, Wed, 4 Jul 2007 10:46:23 +0300 |=3D-
> -=3D| Damyan Ivanov, Tue, 26 Jun 2007 14:01:56 +0300 |=3D-
> > If there are no objections, I can try to prepare a patch for the
> > build system.
>=20
> Please find attached a patch that changes the posix build system as
> follows:
(Full mail at [1]; Whole thread at [2])

After one week without objections/comments, I assume that either
a) the patch is OK
b) there are more important things to do
c) everyone is on vacation
d) something else

Can someone shed some light which of the above is true?


Thanks,
	dam

beware of wraps:
[1]
http://sourceforge.net/mailarchive/message.php?msg_name=3D20070704104623.0c=
38cbd8%40localhost
[2]
http://sourceforge.net/mailarchive/forum.php?thread_name=3D20070609165845.5=
b5479d5%40localhost&forum_name=3Dfirebird-devel
--=20
dam            JabberID: da...@ja...

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

[Dmitry Y. <fir...@ya...>]

Damyan Ivanov wrote:
> 
> After one week without objections/comments, I assume that either
> a) the patch is OK
> b) there are more important things to do
> c) everyone is on vacation
> d) something else
> 
> Can someone shed some light which of the above is true?

Alex is on vacation.


Dmitry

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.

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

[Martijn T. <m.t...@up...>]

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

Ah, but _is_ it an embedded server? IMO, it isn't. Does it accept incoming
connections? No, it does not, so it's not a "server". (yes, it has the
server
code et all, but doesn't "serve" anything).

Wouldn't this rather be called "Firebird Direct Access" or something? Cause
you don't need a running service to access your database?

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

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

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

On Wednesday 18 July 2007 12:11, Martijn Tonies wrote:
> > Why almost - libfbembed is not only an embedded server. It's also the
>
> Ah, but _is_ it an embedded server? IMO, it isn't. Does it accept incoming
> connections? No, it does not, so it's not a "server". (yes, it has the
> server
> code et all, but doesn't "serve" anything).
>
> Wouldn't this rather be called "Firebird Direct Access" or something? Cause
> you don't need a running service to access your database?

Well, certainly embedded access library will be more precise here. It's more 
traditional then direct and will be faster understood by most people - at 
least on this list.
But as long as we anyway have "SQL server" term (even using embedded access), 
I hope that my use of "embedded server" is also not SO awful:)

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

[Martijn T. <m.t...@up...>]

> > > Why almost - libfbembed is not only an embedded server. It's also the
> >
> > Ah, but _is_ it an embedded server? IMO, it isn't. Does it accept
incoming
> > connections? No, it does not, so it's not a "server". (yes, it has the
> > server
> > code et all, but doesn't "serve" anything).
> >
> > Wouldn't this rather be called "Firebird Direct Access" or something?
Cause
> > you don't need a running service to access your database?
>
> Well, certainly embedded access library will be more precise here. It's
more
> traditional then direct and will be faster understood by most people - at
> least on this list.
> But as long as we anyway have "SQL server" term (even using embedded
access),
> I hope that my use of "embedded server" is also not SO awful:)

Reason I'm raising this, is that there are "servers" out there that have
true
embedding. For example, MySQL Server has an embedded mode so
that your application becomes the service, so does NexusDB.

In the support list, it also confuses quite a lot of people, cause they
think
"embedded" means their app becomes the service as well.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

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

[Dean H. <dea...@dl...>]

> Reason I'm raising this, is that there are "servers" out there that
> have true embedding. For example, MySQL Server has an embedded mode so
> that your application becomes the service, so does NexusDB.

I think "embedded server" is still the correct term, though. Just because
the connection isn't made out-of-process doesn't mean it's not a
client/server architecture.

Dean.

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

[Martijn T. <m.t...@up...>]

> > Reason I'm raising this, is that there are "servers" out there that
> > have true embedding. For example, MySQL Server has an embedded mode so
> > that your application becomes the service, so does NexusDB.
>
> I think "embedded server" is still the correct term, though. Just because
> the connection isn't made out-of-process doesn't mean it's not a
> client/server architecture.

That's not the issue, the issue is that your process (including fbembedded)
can't act as a server to other processes, so it doesn't "serve". Hence, it's
not a server embedded in your application.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

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

[Dean H. <dea...@dl...>]

> That's not the issue, the issue is that your process (including
> fbembedded) can't act as a server to other processes, so it doesn't
"serve". Hence,
> it's not a server embedded in your application.

Well, I kind of disagree. Just because you can't serve *other* processes,
fbembed is still serving *your process*. The communication between fbembed
and your app is in-process but it is not any less client/server.

In other words, you're "embedding" the "server" into your process. But that
does not *have* to mean your process becomes a server itself.

Dean.

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

[Martijn T. <m.t...@up...>]

> > That's not the issue, the issue is that your process (including
> > fbembedded) can't act as a server to other processes, so it doesn't
> "serve". Hence,
> > it's not a server embedded in your application.
>
> Well, I kind of disagree. Just because you can't serve *other* processes,
> fbembed is still serving *your process*. The communication between fbembed
> and your app is in-process but it is not any less client/server.
>
> In other words, you're "embedding" the "server" into your process. But
that
> does not *have* to mean your process becomes a server itself.

As where it's confusing to others and different from other systems.

I agree with you on the technical part, but nevertheless, it adds to the
confusion.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

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

[Dean H. <dea...@dl...>]

> I agree with you on the technical part, but nevertheless, it adds to
> the confusion.

Fair enough, I suppose :-) Maybe "fbdirect" or "fbinproc" is what you could
call it instead?

I think the problem with renaming it, though, would be that people looking
for the functionality that it *does* provide (i.e. in-process access to a
database) would also search for "embedded" -- I remember that's how I found
out about firebird in the first place (I wanted an in-process database for a
desktop application, so I googled for "embedded database" and firebird was
on the first page of results)

Dean.

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

[Roman R. <rro...@ac...>]

> Well, I kind of disagree. Just because you can't serve *other* processes,
> fbembed is still serving *your process*. The communication between fbembed
> and your app is in-process but it is not any less client/server.
> 
> In other words, you're "embedding" the "server" into your process. But that
> does not *have* to mean your process becomes a server itself.

Similar discussion was done when Jim were presenting his ideas in 
FB-Architect. Finally it seems to be an agreement that we have "server" 
and we have "engine". So what you call an "inprocess" server is 
something we call "embedded engine".

So unless the core devs disagree, I'd say that we stick to "server" as 
something that can receive requests from other processes (IPC or TCP) 
and "engine" as something that can handle all database operations. Note 
that "server" includes "engine".

Roman

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

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

Any progress here?

I've split the patch to several parts for hopefully easier review:

soname-build.patch
==================
 - changes the soname of the embedded library to
   libfbembed.so.${MajorVer}.${MinorVer}
 - changes the soname of the client library to libfbclient.so.2 and the
   file name to libfbclient.so.2-${FirebirdVersion}

soname-rpm.patch - adapts the RPM building accordingly
soname-sinixz.patch - same for sinixz
soname-solaris.patch - same for Solaris
-- 
dam            JabberID: da...@ja...

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

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. 

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

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

Hi, Alex,

Foreword: The topic is quite complicated and I am certain that I don't
know all the answers. If something from the writings below is not clear,
blame me and ask for clarification.

-=| Alex Peshkov,  6.08.2007 14:13 |=-
> 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.

OK. That "primary" thing was wrong to mention.

What is important is that soname represents library API+semantics. If we
assume libfbembed = embedded_engine+server+client, then change in one of
the components results in change of the sum of them, because there is no
prior knowledge which of the components a given binary needs when
linking with libfbembed.

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

The name of the package which contains the library, changes when the
soname changes.

This allows packaged applications that need given soname to depend on
the respective binary package.

> I agree that almost all programs, that used firebird API 1.x will work just 

"almost" is not good enough when we seek 100% binary+behaviour compatibility

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

When you link a program using -lfbembed, the linker actually looks at
/usr/lib/libfbembed.so. This is usually a symlink to the current version
of the library, say libfbclient.so.2. The library file has the SONAME
symbol in it:

$ objdump -x /usr/lib/libfbembed.so.2 |grep SONAME
  SONAME      libfbembed.so.2

Ths soname is then written in the binary as a NEEDED symbol:
$ objdump -x /usr/lib/firebird/2.0/bin/fb_inet_server | grep embed
  NEEDED      libfbembed.so.2

That NEEDED symbol is used by the run-time linker for loading the
correct library file and binding the application's symbols.

If there is no library providing that soname, fb_inet_server would fail
to start due to unresolved symbols, yes. But it is not all about the
symbols only. Soname is about the semantics, provided by these symbols too.

If libfbembed 2.1 is installed using the same soname, it would be used
without anybody noticing. Why this is bad is not very obvious, unless
you consider application, other that fb_inet_server.

If I have application X, linked with libfbembed, I want it to work
consistently across all installations I have. If one of these
installations have libfbembed 2.1 installed, without soname change, then
the databases produced by this instance would not be compatible with the
other instances (aside of the problems that the application may fail in
many ways due to changed SQL semantics).

In this regard libfbembed is quite different from libfbclient.
libfbclient is more like a "pipe" and noone can't guarantee that the
remote server will not change semantics. libfbembed, however, when used
as an embedded engine can and should guarantee consistency.

I realise that with FB3.0, all this will change. The single client
library will be more like a switch, allowing usage of different engines.
I guess, however, that the engines themselves will not be changed
incompatibly, instead, new engines will be included as firebird evolves.

Ah, and that change in FB3, may deserve soname change 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.
> 
> 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?

I meant that changing the soname more often that strictly necessary
would not be a problem.

For example libfbclient needs not to change its soname between versions
2.0 and 2.1, because all the symbols+semantics from 2.0 are also present
in 2.1 (regardless of whether 2.1 adds new symbols/semantics).

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

I am confused which "approach" you mean here. Changing the sonames with
each[1] release? BTW, if this is what the project needs, the patch is
equally easy to produce.
-- 
dam            JabberID: da...@ja...

[1] "each" meaning 2.0 vs 2.1 vs 2.2, not 2.0.0 vs 2.0.1 or 2.1.0 vs
2.1.1 etc.

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

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

On Monday 06 August 2007 17:18, Damyan Ivanov wrote:
> Hi, Alex,
>
> Foreword: The topic is quite complicated and I am certain that I don't
> know all the answers. If something from the writings below is not clear,
> blame me and ask for clarification.

Damyan, one little thing to adjust.
Suppose we have application originally linked with libfbclient.so.2.1 having 
soname libfbclient.so.2.0. Me thinks it's desirable to have it working 
correctly with libfbclient.so.2.0? This may not always be so. I.e. building 
with version N, and using with N+M is OK - should be OK if no new errors :-), 
but building with N and using with N-M may be bad even in subreleases.

For example (it's about windows, but something similiar may be applied to 
linux too in the future). Version 2.1 has trusted authentication capability 
with server 2.1 (or higher), running on windows server. Application certainly 
may relay on it, even not providing login box at all. Be sure, it will not 
work with old client.

I always thought that package managers can solve this problem with some better 
logic than simple comparison of 2 text strings like soname works. The same 
applies to fb3 architecture - people will be able to have fb4 with it's 
libfirebird.so.4.x installed, but it will be able to call old engine for old 
databases. On my mind, use of libfirebird.so with version even in point 
release smaller then required by program is bad - it can contain bugs fixed 
only on the next point release, but present in old one and preventing program 
from normal operation.

I believe we can invent some hack for 2.1, but much more interesting now (me 
thinks) is preparing the 'ideal' requiremnets from the project to so naming, 
is not it so? And deal with 2.1 in that same manner.

Alex.

PS. Happened to be not very 'little thing' :)

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

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

Hi, Alex,

Thank you for reading so far. Here's another long mail you may leave for
the weekend (I hope not though) :)

-=| Alex Peshkov,  7.08.2007 12:05 |=-
> Suppose we have application originally linked with libfbclient.so.2.1 having 
> soname libfbclient.so.2.0. Me thinks it's desirable to have it working 
> correctly with libfbclient.so.2.0? This may not always be so. I.e. building 
> with version N, and using with N+M is OK - should be OK if no new errors :-), 
> but building with N and using with N-M may be bad even in subreleases.

This is the way I see it too.

> For example (it's about windows, but something similiar may be applied to 
> linux too in the future). Version 2.1 has trusted authentication capability 
> with server 2.1 (or higher), running on windows server. Application certainly 
> may relay on it, even not providing login box at all. Be sure, it will not 
> work with old client.

Windows traditionally keeps backwards compatibility. When this is not
possible, the API is *extended* with new functions (xxx2, xxx_ex), but
old functions are kept. POSIX' approach is quite different.

> I always thought that package managers can solve this problem with some better 
> logic than simple comparison of 2 text strings like soname works.

They do, actually :)

For Debian[0], the package build process uses some additional
information, provided by package maintainer[1] in order to figure out
the necessary dependencies. This result is like this:

You build package X using package libfbclient2 (version 2.1.0,
containing library with soname libfbclient.so.2), The resulting package
X specifies "Depends: libfbclient2 (>= 2.1.0)". This way, the package
manager will not allow package X to be installed, unless a version
later-or-equal than 2.1.0 of package libfbclient2 is installed,
guaranteeing that all functionality of the library is here.

The same holds when X is built using libfbclient2, version 2.0.1 (same
soname). X would then use "Depends: libfbclient (>= 2.0.1)". And the
resulting package will continue to be installable when the libfbclient2
package is upgraded to version 2.1.0.

Note that package manager handles only the installability of a package.
In order for the application contained within the package to continue to
work, it is strictly necessary that the new library version is 100%
backwards-compatible. It may add new functionality/API, but the
functionality and API of the old version must be preserved exactly
(minus bugfixes, of course).

Soname changes kick in when the requirement for 100% backward
compatibility is not satisfied (example libfbembed 2.1 has stricter
requirement on SQL). Such changes come with soname change, which is
reflected by binary distributions by package name change, keeping the
old package for the other packages that still depend on it and providing
a new one for newly built applications. Another useful application of
this is that I can have gbak/isql/etc linked with old and new libfbembed
installed at the same time, allowing me to migrate databases between
versions.

> The same 
> applies to fb3 architecture - people will be able to have fb4 with it's 
> libfirebird.so.4.x installed, but it will be able to call old engine for old 

FB3+ is very different beast, see my comments below.

> databases. On my mind, use of libfirebird.so with version even in point 
> release smaller then required by program is bad - it can contain bugs fixed 
> only on the next point release, but present in old one and preventing program 
> from normal operation.

Do I understand correctly that you prefer changing soname on each minor
release even when backward compatibility is kept? As I hope I made clear
above, this is not necessary for Debian. It is my belief this is not
necessary for other distributions too. Additionally, unnecessarily
changing soname creates additional burden to maintainers of packages
that depend on the library (QT, PHP, python).

> I believe we can invent some hack for 2.1, but much more interesting now (me 
> thinks) is preparing the 'ideal' requiremnets from the project to so naming, 
> is not it so? And deal with 2.1 in that same manner.

It depends of which problems you want to solve. I believe that all
binary distribution are fine if soname is changed only when new library
version is not 100% backwards compatible.

Now, for FB3. From my blurred understanding, any approach we take with
2.1 would not be 1:1 applicable to FB3. FB3 is much different. There
will be one central library (libfirebird[2]) that will be used to "pipe"
access to the relevant engine, authentication provider etc. Applications
would link with libfirebird only and ask for provider, auth etc.

(this and below are my guesses about the future FB3 architecture, but
still may have valid points)

Each such provider then lives in its own shared library, which is used
only by libfirebird. Perhaps it would be then even possible to make
older libfirebird talk to newer providers, as long as the interface
between them is compatible. I think that soname is irrelevant for
provider libraries, since they are loaded using dlopen() and not by the
dynamic linker.

So instead of one library, we have several. Typically, an application
needs the "switchboard" plus some db provider plus some authentication
provider.

The fact that applications link only with the "switchboard" limits the
usability of soname for keeping track of compatibility information. It
is still useful, but only for the communication between the application
and the switchboard, which, in my understanding, would be quite limited.
Since the switchboard interface won't be that complicated, it will very
seldom change without keeping backwards compatibility.

The task about keeping the compatibility with regards to database
interaction is then responsibility of relevant providers. If an
application requests 'engine7' provider, it will get that if it is
available and get error at API-level otherwise. The important thing is
that the interface to 'engine7' and its semantics (behaviour) should not
change. In other words, we have "provider name" instead of "soname" and
the concept of "change only if not back-compatible" can be kept. That
could be extended if application is able to ask for specific versions of
the 'engine7' provider, but I still think that managing backward
compatibility within the provider is the only sane thing to do.

Note that this all is more-or-less about embedded-style of applications,
which are minority. Other, "normal" applications can't be guaranteed to
talk to certain version of the server unless they check that by
themselves. And there is nothing soname or package maintainer can do
about it.


Footnotes:
[0] I believe other binary distributions are similar in this regard

[1] Package maintainer is a real person (or a group of persons)
responsible for maintaining the packages. Not to be confused with
"package manager", which is a set of distribution-specific tools for
managing packages -- dpkg/apt for Debian, rpm/yum/apt for Red Hat etc.

[2] the name here is arbitrary. It only must be different from any other
name used before (libfbclient etc)
-- 
dam            JabberID: da...@ja...

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

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

-=| Damyan Ivanov,  7.08.2007 17:09 |=-
> Thank you for reading so far. Here's another long mail you may leave for
> the weekend (I hope not though) :)

A week later, still no reply. Just a reminder :)
-- 
dam                JabberID: da...@ja...

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

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

On Wednesday 15 August 2007 00:39, Damyan Ivanov wrote:
> -=| Damyan Ivanov,  7.08.2007 17:09 |=-
>
> > Thank you for reading so far. Here's another long mail you may leave for
> > the weekend (I hope not though) :)
>
> A week later, still no reply. Just a reminder :)

We have time till 2.1 release :)