[pkg-firebird-general] Bug#448960: firebird2.0: Uses ICU 3.6, creating databases that are silently incompatible with upstream

Damyan Ivanov dmn at debian.org
Thu Nov 1 21:40:57 UTC 2007


Package: firebird2.0
Version: 2.0.0
Severity: serious

I was going to use "grave", but there is no really danger of data loss,
only very hard to detect, ugly and surprising incompatibility with
upstream's binary database files, possibly leading to incorect query
results. I (as maintainer) certainly don't want such incompatible
version to be released as "stable".

The thread discussing this on upstream mailing list starts at
http://sourceforge.net/mailarchive/forum.php?thread_name=200710311235.13978.peshkoff%40yaroslavl.ru&forum_name=firebird-devel
(approximatelly. SF mailing list web archives suck)

In short, from version 2.0 Firebird uses ICU for collation. Collation
means representing any given string via a binary sequence that can be
easily compared (byte-by-byte). This binary representation is used in
Firebird indices, in the database file.

>From time to time, ICU developers find errors in the binary
representations and fix them.

The problem is that Debian packages of firebird2.0 use the system-wide
ICU (3.6), while upstream uses an older version (3.0), bundled together
with Firebird sources. So any database created by Debian packages that
uses unicode collations would contain in its indices binary
representations that are silently incompatible with upstream.

For Debian, I'll fix this by using the bundled ICU again. This means
alwo enabling rpaths. Ugly, but it will work. Users will have to backup
and restore their databases.

Upstream, on the other hand implemented a better approach for the next
versions of Firebird (2.1+) - each collation remembers with which
version of ICU it was created and any attempt to use it with
incompatible ICU version results in an error. Backup&restore agains
solves the incompatibility. this approach will again allow Debian
packages to use system-wide ICU without uncaught incompatibilities.

Instead of backup&restore, a more fine-grained method would be to
re-create the affected indices: "alter index $index_name active" should
do it.

-- 
    dam





More information about the pkg-firebird-general mailing list