aspell-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]