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