On Tue, May 24, 2005 at 03:13:41PM +0200, Matthias Klose wrote:
> Package: aspell
> 
> Many aspell dictionaries depend on the libaspell15 package. with the
> next soversion (or the coming C++ ABI change), the package name has to
> be changed, as well as other 24 dictionary packages. That's just a
> maintainance burden. Package dictionaries may depend on aspell (>=
> 0.60) instead, but you may argue, that the aspell binary isn't
> necessarily needed. Proposing:
> 
> - a new libaspell package, which depends on the current libaspell15
>   package (a provides is not enough, because dictionaries have to
>   depend on an version, and versioned provides don't yet exist)
> 
> - alternatively dictionary packages should depend on aspell.
> 
> - a short paragraph in README.Debian as a mini policy.
> 

Hi, Matthias and Brian

Just to note that after Brian suggestion, one of the things that are waiting
in dictionaries-common for sarge release is aspell-autobuidhash, allowing the
binary hashes being built from dict postinst. This is still very
experimental, and would require for dicts using it that not only libaspellxx
is installed but also aspell-bin, but should make dependencies simpler for
those dicts, since the dependency would be on aspell-bin, which is synced to
the appropriate libaspellxx because it depends on it.

This has the advantage that dicts will be arch: all packages, because
endianess would be dealt with at hash building (our mirrors will be happy).
The drawback is that aspell-bin is required, that more space is used in the
system and that for slow systems the on-the-fly build might not be as fast as
expected (aspell efficiency on this is much higher now, so this might no
longer be a problem, but is still to be tested with aspell-0.60)

Apps using aspell should depend on the libaspellxx they are linked to, as
currently.

[No need to cc me, I am subscribed to aspell PTS]

Cheers,

-- 
Agustin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to