[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspell-devel] New Aspell Snapshot and Experiential Dictionaries Now
From: |
Kevin Atkinson |
Subject: |
Re: [aspell-devel] New Aspell Snapshot and Experiential Dictionaries Now Available |
Date: |
Mon, 5 Apr 2004 16:34:33 -0400 (EDT) |
On Mon, 5 Apr 2004, Brian Nelson wrote:
> 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/ .
Thanks. I will add a link.
> 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)
> [...]
Yes I know. The question is should I break binary compatibility with
Aspell 0.50 so that both Aspell 0.50 and 0.60 can exist? Except for some
very minor changes Aspell is really binary compatible with 0.60. Is there
some way to have the best of both worlds? That is, is there some way to
install a "dummy" version 15 which really just uses version 16? If there
is then I will increment the soname. If not that the decision is a lot
harder. I could even make it a compile time option so that I don't have
to make the decision. If I do that, the next time I decide to really
break binary compatibility I will use a soname of 17.
> 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.
I think this is a great solution. It will also greatly decrees the
dictionary size.
I also thing that all of Aspell dictionaries should be handled by a single
person since they are in a nice uniform format.
I would be more than willing to work with you to extend my "proc" script
so that it can do almost all of the work for you.
> 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?
I can never promise the dictionary format will stabilize between major
release because I am always adding new features.
--
http://kevin.atkinson.dhs.org