Spec URL: http://ivrix.org.il/redhat/aspell-he.spec SRPM URL: http://ivrix.org.il/redhat/aspell-he-0.9-1.src.rpm Description: 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.
Some suggestions: 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 %files. 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. Issues: rpmlint complains: 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 system-independent. * 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: f453989e1df364af9479e893c16ac9d8 aspell6-he-0.9-0.tar.bz2 f453989e1df364af9479e893c16ac9d8 aspell6-he-0.9-0.tar.bz2-srpm * 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 http://ivrix.org.il/redhat/aspell-he-0.9-2.src.rpm . 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 (MDT) follows: On Sun, 23 Apr 2006, Dan Kenigsberg wrote: >Dear Kevin, > >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 checking in. Extras standards indicate that the buildroot should be: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) and there's no reason to clean out the buildroot at the beginning of %prep. APPROVED