[Pkg-firebird-general] Bug#317314: firebird2: 1.5.2 build (gcc-3.4) ready

[Damyan Ivanov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[This mail got large, due to my attempts to explain the details. Sorry]

Christopher Martin wrote:
> On September 10, 2005 02:01, you wrote:
> 
>>Christopher Martin wrote:
>>
>>>Thanks for working on these packages. However, I tried installing your
>>>packages, but ran into a problem, wherein firebird2-dev tried to
>>>overwrite files in libfirebird2-classic (the package in Sid). So it
>>>looks like there are some missing 'Replaces', and perhaps Conflicts, to
>>>ensure a smooth upgrade for Sid users.
>>
>>Great! Thank you very much for your time.
>>
>>I'll fix this problem shortly.
> 
> 
> Hello,
> 
> Thanks for looking into this.
> 
> It looks like many of the changes mentioned in the firebird2 1.5.2-5 and 
> 1.5.2-6 changelog entries aren't in the actual packages, probably because 
> you made the changes to debian/control, instead of debian/control.in.

I've had some bad ideas about early testing of -6 that you've probably
seen. Please review again 1.5.2-6, it is "officially" released.

All changes are recorded in the SVN repository I am using here (long URL):
http://openfmi.net/plugins/scmsvn/cgi-bin/viewcvs.cgi/people/dam/firebird/?root=dev

Changelog is at (long URL)
http://svn.openfmi.net/dev/people/dam/firebird/tags/1.5.2-6/debian/changelog

> Also, linda reports the following:
> 
> E: firebird2-server-common; Conffile ('/var/lib/firebird2/system', 
> 'security.fdb') is not stored in /etc.

This is intented. There's a lintian override about it.

security.fdb holds user accounts information (usernames and passwords).
It is in /var/lib, because it is writable by the firebird server. It is
marked as a conffile so upgrades do not wipe it out leaving the system
with only admin account enabled and all others removed.

Probably there's better way than using a conffile for this (for example
automaticly importing present accounts into new security.fdb), but
conffile is what the packages used from day 0 and I for one am satisfied
with this. 1.5.1's security.fdb and 1.5.2's are compatible too.

> From this, I noticed that firebird uses /usr/lib/firebird2 as well 
> as /var/lib/firebird2 to store files that probably should not be there, 
> according to the FHS. Since no one has reported this as a bug, and fixing 
> this would probably be a large hassle, I won't insist that this be changed 
> before uploading. But maybe you should add it a TODO list (or let me know 
> if I'm missing something).

/usr/lib vs /var/lib is decided on a case-by-case basis. If you tell me
what looks troublesome to you, I'll try to explain/fix it.

Generally, /var/lib is used for things that need to be writable, and
/usr/lib for libraries. There are several symlinks in
/usr/lib/firebird/{lib,bin} pointing to /usr/{lib,bin} for compatibility
with upstream packaging, which assumes that firebird is installed in
e.g. /opt/firebird and every firebird file can be found in this
"installation root". In debian such root is to be /usr/lib/firebird2.

> Furthermore, firebird2-dev contains symlinks to files in both libfbclient1 
> and libfbembed1. This means that firebird2-dev must depend on both library 
> packages, or there will be dangling symlinks.
> 
> Also, the libgds symlinks are confusing.
> 
> firebird2-dev contains the following:
> /usr/lib/libgds.so -> libfbclient.so.1.5.2
This is a compatibility symlink to allow thirt party software to build
with libgds.so.
> /usr/lib/firebird2/lib/libgds.so -> ../../libfbclient.so.1.5.2
This is for compatibility with upstream's idea of where libraries are
($FB_ROOT/lib). It is not needed by Debian, but can be useful for
third-party software.

> libfbemdeb1 contains the following:
> /usr/lib/firebird2/lib/libgds.so.0 -> ../../libfbembed.so.1.5.2
It is for compatibility with third party software linked with libgds.so.0

> libfbclient1 contains the following:
> /usr/lib/libgds.so.0 -> libfbclient.so.1.5.2
Same as above.

> So three out of four symlinks point to libfbclient.so.1.5.2, but one points 
> to libfbembed.so.1.5.2. Is this deliberate? Shouldn't they all point to the 
> same file? Perhaps libfbemdeb1's symlink should move to libfbclient1 as 
> well.

Hmm. If we want to cover all cases there should be reciprocal links in
libfbembed1 and libfbclient1, i.e:
libfbclient1:
  /usr/lib/libgds.so.0 -> libfbclient.1.5.2
  /usr/lib/firebird2/lib/libgds.so.0 -> ../../libfbclient.1.5.2
libfbembed1:
  /usr/lib/libgds.so.0 -> libfbembed.1.5.2
  /usr/lib/firebird2/lib/libgds.so.0 -> ../../libfbembed.1.5.2

But this shall make libfbclient1 and libfbembed1 to conflict with each
other, forcing split of -dev packages too. This is something I'd like to
avoid.

So I've decided to drop compatibility with third party software (this is
what libgds.so thing is all about) linked with libfbembed (rare case
anyway) and provide the above links in libfbclient1 only.
Changes are described in debian/NEWS.


libfbclient vs. libfbembed and their relation to libgds thing is kind of
confusing. Let's see if I can explain it right.

Firebird has two flawours

classic - that uses separate server process (started from [x]inetd) for
each connection. Server is fb_inet_server and is linked with libfbembed.
libfbembed is kind of self-contained server and can be used to directly
manupulate firebird databases. That's why it is called "embedded" - it
does not need a server process. fb_inet_server is only a glue. All
binaries from -utils-classic are linked with libfbembed. Communication
between different instances of fb_inet_server is acomplished using
semaphores and a dedicated lock manager - fb_lock_mgr.

super - this is a monolith approach - there is a dedicated server
process (fb_server) that listens on a TCP socket and uses threading.

Both server types have good and bad sides. super server uses a
server-wide cache, but can't use more than one processor. Classic, on
the other hand, scales perfectly on SMP system, but each connection has
its own cache.

That was for servers. Client libraries (libfbembed and libfbclient) are
capable of connecting with both server types, with the difference that
libfbembed can also work directly with local databases, without separate
server process, using fb_lock_mgr for IPC. libfbclient needs a server
listening on a tcp socket.

As for development, typical programs link with libfbclient.
There are cases when linking with libfbembed is desirable also - for
example if the program in question is an embedded application and a inet
socket listening server process is not wanted.

My intention when making -dev depend on libfbclient *or* libfbembed was
that a package build-depending on -dev should choose which of
libfbembed/libfbclient it needs and build-depend on it too. Now that you
bring up the question, I see that there's no problem for -dev to depend
*both* on libfbembed and libfbclient, thus saving potential burden on
packages depending on -dev - they can simply depend on -dev and have
both libfbembed and libfbclient at their disposal.

gds.so is another story.

Historically, there was only libgds.so and no libfbembed.so, neither
libfbclient.so.
The upstream "classic" package contained libgds.so, that had the
capabilities of the present libfbembed.so, and upstream "super"
package's libgds.so had the capabilities on present libfbembed.so.

Recently (1.5 branch) upstream renamed client libraries, so now we have
separate libfbembed.so and libfbclient.so. libgds.so links are here for
compatibility reasons.

Having said that I think libgds.so.1.5 symlinks should be included only
in libfbclient for compatibility with non-debian software that uses it.
I've put a libgds.so --> libfbclient.so symlink in -dev too.

Why symlink to libfbclient and not libfbembed? Because most third party
programs want a client library and not an embedded server. In case an
embedded library is needed, we're compatible with upstream in providing
libfbembed.so symlinks.


> Also, please check the changelog for typos before preparing the next upload. 

Done. I've proofread them, and used ispell. Thanks for spotting.

1.5.2-6 is in ftp://www.creditreform.bg/public

Upgrade of firebird2-dev from 1.5.1-4 is like this:

`apt-get dist-upgrade'
  install libfbclient1, removes libfirebird2-classic
  doesn not upgrade firebird2-dev
`apt-get dist-upgrade' # second run
  upgrade firebird2-dev
  install libfbembed1

`aptitude dist-upgrade' does the same, but in one step.


> Once these issues are sorted out, I'll take another look at the package, 

I did my best.

> and hopefully be able to upload it for you. Thanks for all your work on 
> firebird2.

Now *that* would be great! I started to think that I'll have to run for
becoming a DD to get this in the archive :-)
Your help is very much appreciated.



Kind regards,
dam
- --
Damyan Ivanov          0x9725F63B          Creditreform Bulgaria
divanov at creditreform.bg              http://www.creditreform.bg/
phone: +359(2)928-2611, 929-3993            fax: +359(2)920-0994
mob. +359(88)856-6067  ICQ 3028500  dam at jabber.minus273.org/Gaim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJsEgHqjlqpcl9jsRAv9hAKCJPh0DhAW6FnCH/QcxddAGz/NSNwCguxIi
NbDdziYyDOgmLsA2TUg07PQ=
=DlN/
-----END PGP SIGNATURE-----