Re: [aspell-devel] New Aspell Snapshot and Experiential Dictionaries Now Available

[Brian Nelson]

Kevin Atkinson <address@hidden> writes:

> A new Aspell snapshot is now available: 
>   ftp://alpha.gnu.org/gnu/aspell/aspell-0.60-20040402.tar.gz

I've put up some experimental Debian packages of this release at
http://people.debian.org/~pyro/experimental/ .

> Major Changes in This release:
>
>   * Lots of bug fixes
>   
>   * The dictionary format unfortunately changes again due to a number of
>     bugs that were discovered
>
>   * The format and name of the character set data file changed again.
>     The extension changed from .dat to .cset.  The format and name
>     should be stable now.
>
> Other important changes that were introduced with the 20040317 snapshot:
>
>   1) I decided to name the next Aspell version 0.60 since almost every 
>      part of Aspell has been refactored or rewritten to some extent.
>
>   2) Dictionaries and data files are now installed in LIBDIR/aspell-0.60 
>      so that Aspell 0.50 and 0.60 can more peacefully coexist.

This isn't enough to allow 0.50 and 0.60 to coexist, at least on Linux
systems since the library still shares the same soname:

$ ldd /usr/bin/aspell
       libaspell.so.15 => /usr/lib/libaspell.so.15 (0x40025000)
       [...]

Thus, the runtime linker won't be able to decide which library version
to use.

The unchanging soname coupled with the changing dictionary format also
presents a problem for the Debian packaging.  When I packaged 0.50, I
made a guess that dictionary format changes and soname changes would
generally happen together (usually with major releases), based on the
release history.

In order to provide a correct upgrade path to 0.50, I had to make the
0.50 packages conflict with *all* of the dictionary packages that were
using the pre-0.50 format.  This is a very ugly solution that is frowned
upon in Debian Policy because dpkg can't handle the situation very well.
(Quoting policy: "A Conflicts entry should almost never have an "earlier
than" version clause. This would prevent dpkg from upgrading or
installing the package which declared such a conflict until the upgrade
or removal of the conflicted-with package had been completed.")

In an attempt to avoid this problem with future Aspell releases, instead
of having the Aspell dictionary packages depend on the "aspell" package,
I made them depend on the "libaspell15" package.  First of all, this
relationship is more logical since only the library needs to be
available to make use of the dictionary, and more importantly, the
dictionary is bound to the library of that particular soname.  So, if
the next release of Aspell with a new dictionary version were to bump up
the soname, the upgrade path would be handled gracefully without the
need for complicated conflicts declarations.  The dictionary packages
would simply need to be rebuilt to depend on libaspell16 (or whatever
soname is chosen), end of story.

If Aspell 0.60 does *not* change the soname, then the situation will be
much messier.

I think the optimal solution to this problem would be to build the
dictionary at install time, meaning the package contains a wordlist as
distributed in the dictionary tarballs and runs word-list-compress on it
when installing (sort of like how Emacs lisp packages byte-compile at
install time).  This has a couple big advantages:

  1. The dictionary packages can be "Architecture: all" since they will
     no longer be arch-specific, meaning the Debian mirrors would no
     longer need to have 11 large .debs for each Aspell dictionary.

  2. Updating the dictionaries when the format changes would be trivial
     and wouldn't even require a new package upload.  Installing the new
     Aspell debs would simply new to trigger a rebuild of the currently
     installed dictionaries.

The drawbacks to this solution are additional complexity and work for me
to implement the infrastructure needed to build dictionaries at install
time.

What do you think of this approach?  Would it be worth the effort?  Or,
do you think the dictionary format will stabilize in the near future so
that changes to it will be few and far between?

-- 
You win again, gravity!