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
Summary: | Review Request: aspell-he | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Kenigsberg <danken> |
Component: | Package Review | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-04-24 19:43:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779 |
Description
Dan Kenigsberg
2006-04-17 17:28:01 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. 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 |