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.
*** 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.ac.il.
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.
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.
Post a new SRPM, and I'll do the review on that.
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.
Created attachment 119017 [details] suggested spec rel. 4
(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. :)
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.
Created attachment 119238 [details] suggested spec rel. 5
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. :)
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)?
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.
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)
Short Answer: The lawyers want us to do it.
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
yes, this is a fine place to ask. ;) cvs done.