Bug 177707 - Remove app-text/hspell from tree
|
Bug#:
177707
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: alonbl@gentoo.org
|
Reported By: alonbl@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: Remove app-text/hspell from tree
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-08 19:44 0000
|
Hello,
Currently hspell is not maintained, while apsell and hundspell took the same
dictionary and are maintained.
I would like to remove hspell from tree. Can you please remove the dependency
from the following packages? Aspell should work in both cases, if LINGUS has
"he".
Thanks.
---
treecleaner:
app-editors/geresh (Some discussion of removing at bug#149758)
gnome-office:
app-text/enchant
is there any gnome-office?
I guess there is no gnome-office... So I will do this myself.
I just realized today I wasn't in gnome-office, although I'd thought I was. If
you've already done this, then good, otherwise I'll look at it.
I hoped someone will reply :)
Please check it out... Just remove the dependency should be simple.
Thanks!
Sorry for the delay. Enchant is done.
If Enchant and Geresh are done, shouldn't this bug be closed?
Thanks!
But I need kde to drop dependency first (kdelibs-3.5.5-r10).
(In reply to comment #13)
> But I need kde to drop dependency first (kdelibs-3.5.5-r10).
What dependency? ;-)
I've just dropped it.
Thanks!
But you should also remove:
if use spell; then
myconf="${myconf} $(use_with linguas_he hspell)"
else
myconf="${myconf} --without-hspell"
fi
And use --without-hspell as static.
Arg... I really shouldn't work on the tree when I'm excessively tired. :)
Fixed and thanks for letting me know.
Hi, as the author of Hspell I'd like to offer some clarifications.
First, what you have in your "hspell" package is the "hspell" command-line
program, which implements the old Unix "ispell -a" and "spell" spell-checking
interfaces, for the Hebrew language only. While it focuses on a single task
only (and is not a multi-lingual spell-checker), it does this single task
better than aspell's Hebrew dictionary (see more below) - it handles better a
few cases (like words that must have a prefixes, and gimatria), it starts up
much faster, and takes up less memory - and much less disk space (just 100 KB
for the Hebrew dictionary!). It also has Hebrew-specific correct suggestions,
and if compiled with this flag, also has an additional "morphological analyzer"
feature.
Aspell's Hebrew dictionary is based on Hspell's data, and always created from
its last release. The great thing about this dictionary is that any application
that knows how to use aspell, can use this dictionary, and this is how, for
example, GMail and OpenOffice can easily boast a Hebrew speller just like they
have French or Spanish spell-checking. The problems with this implementation is
like I mentioned above - it takes a long time to start (because of Hebrew's
long list of complex prefixes and long list of words), uses a lot of memory,
and makes correction suggestions which are more often than not, silly.
I think the ideal thing is - at least until aspell's performance issues are
solves - is to have both hspell and aspell's Hebrew dictionary installed. The
former would be used by applications that know how to use it directly, and the
latter will be used by those who don't.
Saying that the "hspell" command line tool isn't maintained is not entirely
accurate. True, the tool's code itself is rather static, and somewhat
anachronistic (e.g., expects the ISO-8859-8 encoding), but the applications
that use it have learned to work with these ideosynchracies. On the other hand,
"hspell"'s dictionary *is* maintained, and will always be more up to date than
the one from the Aspell site.
Hello Nadav,
Thank you for your comment.
(In reply to comment #17)
> Saying that the "hspell" command line tool isn't maintained is not entirely
> accurate. True, the tool's code itself is rather static, and somewhat
> anachronistic (e.g., expects the ISO-8859-8 encoding), but the applications
> that use it have learned to work with these ideosynchracies. On the other hand,
> "hspell"'s dictionary *is* maintained, and will always be more up to date than
> the one from the Aspell site.
>
We discussed this offlist...
Currently the hspell library and application have some main issue:
1. You don't create PIC shared library, so we had to create a long patch to use
autoconf/automake/libtool in order to do this. As you rejected this patch and
did not provide your own implementation, we back to square one, require to drop
this package.
2. Your interface is none UTF-8 (None standard in NLS environment), so no new
application will likely use your library, having unique applications such as
kdelibs just makes maintenance more complex.
4. There is no simple ability to translate a mixed (Hebrew/other) text in one
shoot.
5. aspell provide some basic support, maybe someone can do this better, but at
least it is maintained and supported by many applications.
Some references:
http://ivrix.org.il/bugzilla/show_bug.cgi?id=4
http://bugs.gentoo.org/show_bug.cgi?id=152818
http://ivrix.org.il/bugzilla/show_bug.cgi?id=68
http://ivrix.org.il/bugzilla/show_bug.cgi?id=83
I agree that hspell dictionary is more up to date, but with a proper script we
can regenerate updated dictionary.
I recommend you cooperate with hunspell, aspell to integrate your unique
functionality and continue to maintain the word list.
Alon, yes, I'm feeling a bit of a deja-vu over this discussion :-)
I never said that the "hspell" program was perfect. It has its flaws (which
both you and I know) and they are not going to change soon. However, a bunch of
applications which you list in this bug report don't care about these flaws:
they were already written to pass ISO-8859-8 to hspell, they use the "hspell
-i" process, not a library, or use Hspell's tiny static library (so the PIC
issue is moot). The other issues you mention are irrelevant too (aspell also
can't do mixed Hebrew/English/Spanish/whatever spelling).
So my point was, why spend the time modifying the applications that already
call "hspell -i" (or use hspell in whatever way they use it), to use aspell
instead? Of course, it's your prerogative, but if something ain't broken, why
fix it?
Anyway, since I don't use gentoo myself, do what you please in Gentoo :-) The
only reason I'm writing here is because an concerned Gentoo user contacted me
and told me he was bothered by the removal of Hspell, and wanted to know if
there's anything I could do about it.
Hi!
We currently have no dependency of this package.
And you do not maintain (close/comment bugs) the package (lib + tool)
So... I do not wish to maintain such software, especially when in order to make
it work I have to maintain a separate build environment. aspell/hunspell works
find for me.
If a specific user needs it he can continue to use current package copied to
his local overlay.
Alon.