Kevin Atkinson <[EMAIL PROTECTED]> 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! _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/aspell-devel
