Bug 168624 - Review Request: hspell: a Hebrew spell checker
Review Request: hspell: a Hebrew spell checker
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
David Lawrence
http://http://ivrix.org.il/projects/s...
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-09-18 09:51 EDT by Dan Kenigsberg
Modified: 2007-12-26 15:03 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-01 11:15:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kevin: fedora‑cvs+


Attachments (Terms of Use)
new hspell.spec (3.20 KB, patch)
2005-09-19 15:42 EDT, Tom "spot" Callaway
no flags Details | Diff
suggested spec rel. 4 (3.42 KB, patch)
2005-09-20 06:00 EDT, Dan Kenigsberg
no flags Details | Diff
suggested spec rel. 5 (3.66 KB, patch)
2005-09-25 12:01 EDT, Dan Kenigsberg
no flags Details | Diff

  None (edit)
Description Dan Kenigsberg 2005-09-18 09:51:33 EDT
Spec Name or Url: http://www.ivrix.org.il/redhat/hspell.spec
SRPM Name or Url: http://www.ivrix.org.il/redhat/hspell-0.9-2.src.rpm
Description: 

Hspell is a rather-mature (3 years old) free Hebrew spell-checker. It has a Unix-spell-like command-line interface and a pipe interface (similar to ispell -a) for applications.

Hspell has been integrated with many applications such as LyX and ViM (and its word list is used by aspell and OpenOffice). For a long while we (the authors of Hspell) have provided an RPM of Hspell with every release. However, it might be beneficial for users to have this RPM as part of Fedora proper (be it Extra or Core).

Please consider adding hspell to your repository. I hope I generated an RPM which fits your specifications, but I am ready to tweak it further if I am requested to.
Comment 1 Dan Kenigsberg 2005-09-19 12:49:50 EDT
*** SPONSOR HUNTING ***
Oh, I forgot to mention that this is my very first Fedora package, and I am
looking for someone to sponsor me. If you are a potential sponsor, do note that
I am a real person who have been packaging and distributing RPMs for quite a
while now. For more inforamtion see my homepage
http://www.cs.technion.ac.il/~danken/ or contact me via email
danken@cs.technion.ac.il.
Comment 2 Tom "spot" Callaway 2005-09-19 15:31:36 EDT
Hi Dan! I looked over your srpm, and it needed a little cleanup. I'll attach a
new version of your spec to this bugzilla report.
Comment 3 Tom "spot" Callaway 2005-09-19 15:42:20 EDT
Created attachment 119000 [details]
new hspell.spec

I cleaned up a few things:

- It doesn't really make much sense to build a fat vs nofat version of the
package. The added functionality is always good, and it doesn't cause a
significant size difference. Just build with fat support enabled.

- The hack that you're using to eliminate the Requires on perl and friends is
bad, because, well, you're including a perl script binary which really does
need perl, perl(Getopt::Long), perl(IO::Handle), perl(IPC::Open2), and
perl(strict).

- I got rid of a lot of the legacy cruft that was commented out, just makes the
spec cleaner.

- The source file needs to be a full URL, so reviewers can check the upstream
source to make sure it is the same.

- The provides for hspell-fat needs to be a version-release provide.

- BuildRequires: zlib-devel

- I moved the devel definition section up to the top, just for legibility.

- There is no need to specify -n %{name}-%{version} in %setup, this is the
default.

- You can use %configure and eliminate a lot of those manual defines

- For macro consistency (and legibility), I used %{variable} syntax throughout
the spec file.

- you can just do make DESTDIR=%{buildroot} install, instead of the much longer
multiple variable version.

- You want to use %{_datadir}/hspell/ instead of %{_datadir}/hspell/* in
%files, so that you can own that directory (and all the files in it).

- You need to use %defattr for all %files sections (your -devel section was
missing it).

- You probably also want to add a hebrew translation for the %description
devel.
Comment 4 Tom "spot" Callaway 2005-09-19 15:42:53 EDT
Post a new SRPM, and I'll do the review on that.
Comment 5 Dan Kenigsberg 2005-09-20 05:53:02 EDT
Hi Tom, thanks for your review of my spec file and its corrections.

- I believe that for the casual user, the "slim" flavor of the package is
better that the "fat" one. It takes only 200Kb (instead of 700Kb) and would
generate less false positives. Don't misunderstand that I dislike the
morphological analyzer; it is my code and hopefully some great things would be
based on it. But currently I suspect that it is not too useful for John Doe. If
you think differently, please let me know.

- I respect your judgment regarding the perl-require hack. Too bad that we have
so many requirements only because we happen to distribute an addon script that
is written in perl.

- I don't think that there are many developers who needs the Hebrew description
of what a -devel package is. Thanks for suggesting it, though.

- Thanks again for your cleanups.

I attach the slightly changed spec, and put the new SRPM online in
http://www.ivrix.org.il/redhat/hspell-0.9-4.src.rpm . I am looking forward to
hearing your comments.
Comment 6 Dan Kenigsberg 2005-09-20 06:00:10 EDT
Created attachment 119017 [details]
suggested spec rel. 4
Comment 7 Tom "spot" Callaway 2005-09-22 14:57:48 EDT
(In reply to comment #5)
> Hi Tom, thanks for your review of my spec file and its corrections.
> 
> - I believe that for the casual user, the "slim" flavor of the package is
> better that the "fat" one. It takes only 200Kb (instead of 700Kb) and would
> generate less false positives. Don't misunderstand that I dislike the
> morphological analyzer; it is my code and hopefully some great things would be
> based on it. But currently I suspect that it is not too useful for John Doe. If
> you think differently, please let me know.

I think that this is something that you should conditionalize within the
application itself, and enable by default. That way, one binary rpm package
provides the fat functionality for the power users, but it is not enabled by
default to avoid the false positives. I don't think the size difference merits
disabling it by default, since it is only 500K more (if it was 50MB more, then
perhaps).

Basically, what I'm saying is that the binary should come with the fat support
enabled, but in order to use that, they should have to pass hspell -fat (or
something).

> - I respect your judgment regarding the perl-require hack. Too bad that we have
> so many requirements only because we happen to distribute an addon script that
> is written in perl.

Well, you really do want those perl requirements to be there for users, so that
when they go to run that addon script, it actually works. :)

> - I don't think that there are many developers who needs the Hebrew description
> of what a -devel package is. Thanks for suggesting it, though.

You should add it to be complete, or remove the hebrew translation for the base
package. All or nothing, really. :)
Comment 8 Dan Kenigsberg 2005-09-25 11:57:35 EDT
All right, I accepted your changes into
http://www.ivrix.org.il/redhat/hspell-0.9-5.src.rpm . Most of the burden
incurred by the "fat" version is already controlled by command line option (-l).
A user that does not use it will not see any slowdown, only loose 500Kb of disk
space. The alleged problem of accepting rare verb forms is not too serious, and
certainly is not a matter of the RPM. We will reconsider it when it is time to
release a new upstream version.

I thought that adding Hebrew description to a Hebrew-related package is cute. So
I extended this cuteness to the devel package as you suggested.

Please tell me if you have more suggestions.
Comment 9 Dan Kenigsberg 2005-09-25 12:01:46 EDT
Created attachment 119238 [details]
suggested spec rel. 5
Comment 10 Tom "spot" Callaway 2005-09-25 17:18:47 EDT
Review:

Good:

- rpmlint checks return nothing
- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file
- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 

Nitpick:

You should probably include COPYING as a %doc for the main package as well, but
thats a minor issue, not a blocker.

APPROVED.

Go ahead and put in your paperwork for sponsorship, and I'll sponsor you. Good
work. :)
Comment 11 Dan Kenigsberg 2005-09-26 04:21:48 EDT
Tom, thanks for approving Hspell.

You may not be the right person to ask, but I do have a problem with the
Contributor License Agreement. I am happy to grant to Red Hat "a ... copyright
license to ... prepare derivative works" of the hspell.spec file. But by no
means am I in the position to to grant anything beyond the GPL regarding the
upstream software. 

I would like to make sure that Red Hat (and anyone else) know that Hspell is
released by its authors under the GPL. Do you know how I can do it (except for
declaring it clearly in this esteemed hospice)?
Comment 12 Tom "spot" Callaway 2005-09-26 10:25:27 EDT
IANAL, but I think the intent of that is to allow Red Hat (and via Red Hat,
anyone) the capacity to make changes and apply patches to the hspell rpm. For
example, Red Hat might choose to pull hspell into RHEL and make changes.

This doesn't supercede or overwrite the GPL or any of the rights that the GPL
grants. After all, you can't legally take GPL code and change it to a non-GPL
license.

If you're still concerned about the CLA, the only advice i can offer is to
consult your own legal council.
Comment 13 Dan Kenigsberg 2005-09-26 11:37:33 EDT
I fullheartedly support the idea of RedHat adding Hspell (and other
Hebrew-related software) to their distributions, in word and spirit of the GPL.

Speaking about the GPL, and regarding to your "nitpicking": do we really want to
have yet another copy of the GPL inside the Hspell rpm? I suspect that I have
some 250 of them already, scattered among the 400 GPL-licensed rpms that I have!
(How about adding a single GPLv2 rpm, and having each of these 400 rpms require
it? I guess the freed 4Mb-per-installation does not merit the fuss)
Comment 14 Tom "spot" Callaway 2005-09-26 11:42:58 EDT
Short Answer: The lawyers want us to do it.
Comment 15 Dan Kenigsberg 2007-12-26 05:42:19 EST
Package Change Request
======================
Package Name: hspell
New Branches: EL-4 EL-5

someone wishes to see hspell in EPEL, or so it seems in
http://fedoraproject.org/wiki/EPEL/WishList . As I agree to maintain it on EPEL,
too, please open the relevant branch(es).
P.S I ain't sure this is the place to ask for that; this is what I understood
from
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#head-529da50ad0b5cf0bedb9fdf47569c76657d79a7b
Comment 16 Kevin Fenzi 2007-12-26 15:03:34 EST
yes, this is a fine place to ask. ;) 

cvs done. 

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