Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 189157 - Review Request: aspell-he
Summary: Review Request: aspell-he
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-04-17 17:28 UTC by Dan Kenigsberg
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-24 19:43:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dan Kenigsberg 2006-04-17 17:28:01 UTC
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.

Comment 1 Jason Tibbitts 2006-04-23 05:56:07 UTC
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.


Comment 2 Dan Kenigsberg 2006-04-23 10:06:41 UTC
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.





Comment 3 Jason Tibbitts 2006-04-23 17:34:22 UTC
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


Note You need to log in before you can comment on or make changes to this bug.