Looks like support for the FIREBIRD environment variable is broken in the Debian builds for Firebird 2.5. I have so far checked the 2.5.0 and 2.5.1 packages in https://launchpad.net/~mapopa/+archive/ppa and they all seem to exhibit the same problem Also building the packages myself from source (apply patch from ftp://ftp.modsoftsys.net/public/firebird2.5-backports/firebird2.5_2.5.1.26351.ds4-2~bpo60+1.debian.tar.gz) seems to have the same problem. On the other hand, the tar archive on http://www.firebirdsql.org/en/server-packages/ seems to be OK.
As far as I can make out the Debian builds have been built without the BOOT_BUILD environment variable being defined and with explicit paths to various firebird directories. Reading src/common/utils.cpp (line 930 onwards) when the values are set explicitly in this way, the environment overrides have no effect. Running a command such as `strings fbguard |grep "/var/run"` returns /var/run/firebird/2.5 with the affected debian builds, but returns an empty string with the builds on the FIrebird repository. With Firebird 2.1, there was no such problem with the Debian build and soft links were used to direct the Firebird Server from its default directory tree to where Firebird files had been distributed (I assume to follow Debian Guidelines). This raises the following questions: 1. Why was this change made? I can't see any good reason from breaking the FIREBIRD environment variable handing in the Debian builds. 2. Why should setting explicit directory paths be incompatible with use of the FIREBIRD environment variable? A simple test for this variable could be used to ignore the hard wired paths. 3. What is the purpose of this BOOT_BUILD macro in the first place? Some might ask, is this a problem? My answer is that breaking previous behaviour is never a good idea unless there is a compelling reason to do so. Having different behaviour between different architectures is also highly undesirable. For me, it is also a problem as I have a lot of automated test suites for Firebird Client applications that rely on setting the FIREBIRD variable to locate the files outside of the normal operational file hierarchy and hence allow qualification tests to be run on an operational server without disturbing its operational functions. My proposed fix is that if there is a good reason to compile this code section (in utils.cpp) into a final build then there should also be a check for use of the FIREBIRD environment variable and to skip the hard-wired paths if present. Tony Whyman MWA Software ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
