Bug 364211
Summary: | Review Request: ruby-hpricot - A Fast, Enjoyable HTML Parser for Ruby | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> |
Component: | Package Review | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, notting |
Target Milestone: | --- | Flags: | j:
fedora-review+
j: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-11-07 07:48:15 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: | 364221 |
Description
Mamoru TASAKA
2007-11-02 16:44:40 UTC
I had to reacquaint myself with the Ruby guidelines.... One question: This is also available as a gem. If something ends up needing the gem, you'll have to abandon this package and submit rubygem-hpricot for review. So it's worth asking: are you sure that nothing will want this as a gem, and if not then wouldn't it be easier to do it all at once? Regardless, I'll go ahead and review this; a gem package shouldn't be much different. I note there's an hpricot-0.6 tarball on the upstream web site, but I don't know if you'd want to use it. This package looks fine, save for one thing. The guidelines spefically state that you need RuildRequires: ruby. Currently ruby is only being brought in for this build because rake has a dependency on /usr/bin/ruby. I honestly don't know if this is a real issue. Review: * source files match upstream: efbb70d4ee6b79a3cbf7dac24f16646c3ab688812cc2f68ffcf6d3e76e826ec4 hpricot-0.5.150.tgz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly * debuginfo package looks complete. * rpmlint is silent. * final provides and requires are sane: hpricot_scan.so()(64bit) ruby(hpricot) = 0.5.150-2.fc8 ruby-hpricot = 0.5.150-2.fc8 = libpthread.so.0()(64bit) libruby.so.1.8()(64bit) ruby(abi) = 1.8 * %check is present and all tests pass: .............................................................. Finished in 6.535526 seconds. (rake test isn't very verbose about successes) * no shared libraries are added to the regular linker search paths. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * code, not content. * 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 static libraries. * no libtool .la files. ? ruby not required * .rb files stored in sitelib. * arch specific files stroed in sitearch * ruby(name) provided * ruby(abi) required. Chatted with the primary author of the ruby guidelines and he agreed that this usage is OK. We will get that bit of the guidelines changed. APPROVED (In reply to comment #1) > I had to reacquaint myself with the Ruby guidelines.... > > One question: This is also available as a gem. If something ends up needing the > gem, you'll have to abandon this package and submit rubygem-hpricot for review. > So it's worth asking: are you sure that nothing will want this as a gem, and if > not then wouldn't it be easier to do it all at once? Well, in general non-gem ruby module and gem ruby module are the same in function. So I think no one would want gem hpricot if we provide non-gem hpricot in rpm. > > Regardless, I'll go ahead and review this; a gem package shouldn't be much > different. > > I note there's an hpricot-0.6 tarball on the upstream web site, but I don't know > if you'd want to use it. Thank you for information. I will check it later. > > This package looks fine, save for one thing. The guidelines spefically state > that you need RuildRequires: ruby. Currently ruby is only being brought in for > this build because rake has a dependency on /usr/bin/ruby. I honestly don't > know if this is a real issue. Yes, as rake needs /usr/bin/ruby, I removed the explicit BuildRequires. (In reply to comment #2) > Chatted with the primary author of the ruby guidelines and he agreed that this > usage is OK. We will get that bit of the guidelines changed. > > APPROVED Thank you for your review! ---------------------------------------------------------------------- New Package CVS Request ======================= Package Name: ruby-hpricot Short Description: A Fast, Enjoyable HTML Parser for Ruby Owners: mtasaka Branches: FC-6 F-7 F-8 InitialCC: (nobody) Cvsextras Commits: yes My understanding of gems is that it's possible for Ruby code to require the gem in such a way that the non-gem package won't satisfy it. But my understanding of Ruby is rather weak. In any case, CVS is done. Well, rubygem-rake is not on FC-6, so I rebuilt this package on devel, F-8 and F-7, with updated to 0.6. Thank you for your review! Closing. |