Red Hat Bugzilla – Bug 189157
Review Request: aspell-he
Last modified: 2007-11-30 17:11:30 EST
Spec URL: http://ivrix.org.il/redhat/aspell-he.spec
SRPM URL: http://ivrix.org.il/redhat/aspell-he-0.9-1.src.rpm
Provides the word list/dictionaries for Hebrew.
Now that Fedora Core moved to aspell 0.60, we can add a package for Hebrew (from the Hspell project) into Fedora Extras. Actually, it may well go into Fedora Core, and sit besides its peers, but this is not for me to decide.
Note that this package does not pass rpmlint quietly, much like the French package from which I copied its spec. I might be mistaken, but I think that rpmlint is a bit too picky here. It is angry because the binary package is architecture-dependent, yet includes no executable - only compressed list of words. Still, this compressed list *is*, as I believe, architecture-dependent and should be marked as such.
Add a comment explaining why the package can't be noarch. (I'm assuming the
dictionary files are endian or word-length dependent, although the files are
exactly the same on i386 and x86_64.) It would be nice to have some definitive
statement on the matter from the aspell authors; I looked through their
documentation but didn't see anything, and I have no PPC machine to test with.
Remove commented items in the specfile, like the Epoch: line or the last line of
Consider using a here document instead of a bunch of echo statements in %build.
Personal taste; I think it just looks cleaner but it's up to you.
E: aspell-he no-binary
E: aspell-he only-non-binary-in-usr-lib
If we assume that endianness issues prevent the package form being noarch, both
of these are indeed pointless. The package isn't supposed to have a binary and
it's not possible to put things in /usr/share because the data is not
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written, uses macros consistently and
conforms to the Perl template.
* license field matches the actual license.
* license is open source-compatible and is included as %doc.
* source files match upstream:
* BuildRequires are proper.
* package builds in mock (development, i386 and x86_64).
O rpmlint is silent.
* final provides and requires are sane.
* no shared libraries are present.
* package is not relocatable.
* creates no non-doc directories.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* no %check present; no test suite upstream.
* content only, but clearly permissible.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
I cleaned up the spec file as you asked, and put the new version in
http://ivrix.org.il/redhat/aspell-he.spec and the new srpm in
As you asked, I asked the developer of Aspell, Kevin Atkinson, about the
byte-ordering issue. His brief reply, dated Sun, 23 Apr 2006 02:47:11 -0600
On Sun, 23 Apr 2006, Dan Kenigsberg wrote:
>If you recall, once we were working together on the Hebrew support in
>aspell-0.60. I want to push this support into Fedora, but something about it
>worries their automated cleanliness-checking tool (rpmlint).
>Why does aspell's dictionaries sit under /usr/lib/aspell-0.60 ? What causes
>them to be architecture-dependent? Is it byte-order issues?
Yes, its byte-order.
Thanks for tracking down this explanation; this may have been known to the Core
aspell maintainer but in Extras we like to have the specfiles as
self-explanatory as possible.
Everything looks good, except for a couple of things which you can fix when
Extras standards indicate that the buildroot should be:
and there's no reason to clean out the buildroot at the beginning of %prep.